Move most of the error checking for foreign-key constraints out of

parse analysis and into the execution code (in tablecmds.c).  This
eliminates a lot of unreasonably complex code that needed to have two
or more execution paths in case it was dealing with a not-yet-created
table column vs. an already-existing one.  The execution code is always
dealing with already-created tables and so needs only one case.  This
also eliminates some potential race conditions (the table wasn't locked
between parse analysis and execution), makes it easy to fix the gripe
about wrong referenced-column names generating a misleading error message,
and lets us easily add a dependency from the foreign-key constraint to
the unique index that it requires the referenced table to have.  (Cf.
complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.)

Also, third try at building a deletion mechanism that is not sensitive
to the order in which pg_depend entries are visited.  Adding the above-
mentioned dependency exposed the folly of what dependency.c had been
doing: it failed for cases where B depends on C while both auto-depend
on A.  Dropping A should succeed in this case, but was failing if C
happened to be visited before B.  It appears the only solution is two
separate walks over the dependency tree.