2014.10.03 MSS Code Factory 1.11.12423 DelDep specifications passed tests for PostgreSQL

The "Replace Complex Objects" test for CFDbTest 2.0 works again for PostgreSQL.
Now that I've proven in the initial code for implementing deletion dependencies,
the changes can be propagated to the other databases.

DelDep specifications are *not* inherited.  You need to explicitly state them for
each table in a hierarchy if you use them.  This allows subclasses to "tune" the cascading
deletes that are produced.  Also, if a table specifies DelDep specifications, the old
cascading delete code for component/detail/child objects is *not* produced.  So if
you are using DelDep specifications to circumvent a problem with the default cascading
delete behaviour, you must replicate and enhance the DelDep specifications for every
subclass table of the table which was originally causing a problem.

It is also worth noting that the DelDep implementation is not as efficient as
cascading deletes, because it invokes the delete-by-primary-key stored procedure
for the target of the dependancy, which adds an extra stored procedure call compared
to the way cascading deletes are implemented.  On the other hand, cascading deletes
repeatedly invoke the whole delete tree of stored procedures, so there could be cases
where it's actually more efficient to specify DelDeps.

I hope to avoid implementing DelDeps for the three core models (CFSecurity, CFInternet,
and CFCrm) because if any of the tables in those models specify DelDeps, it would force
importers of those definitions to specify additional DelDeps for "hook" objects like
the Cluster and Tenant.