Further fix ALTER COLUMN TYPE's handling of indexes and index constraints.

 Further fix ALTER COLUMN TYPE's handling of indexes and index constraints.
 
 This patch reverts all the code changes of commit e76de8861, which turns
 out to have been seriously misguided.  We can't wait till later to compute
 the definition string for an index; we must capture that before applying
 the data type change for any column it depends on, else ruleutils.c will
 deliverr wrong/misleading results.  (This fine point was documented
 nowhere, of course.)
 
 I'd also managed to forget that ATExecAlterColumnType executes once per
 ALTER COLUMN TYPE clause, not once per statement; which resulted in the
 code being basically completely broken for any case in which multiple ALTER
 COLUMN TYPE clauses are applied to a table having non-constraint indexes
 that must be rebuilt.  Through very bad luck, none of the existing test
 cases nor the ones added by e76de8861 caught that, but of course it was
 soon found in the field.
 
 The previous patch also had an implicit assumption that if a constraint's
 index had a dependency on a table column, so would the constraint --- but
 that isn't actually true, so it didn't fix such cases.
 
 Instead of trying to delete unneeded index dependencies later, do the
 is-there-a-constraint lookup immediately on seeing an index dependency,
 and switch to remembering the constraint if so.  In the unusual case of
 multiple column dependencies for a constraint index, this will result in
 duplicate constraint lookups, but that's not that horrible compared to all
 the other work that happens here.  Besides, such cases did not work at all
 before, so it's hard to argue that they're performance-critical for anyone.
 
 Per bug #15865 from Keith Fiske.  As before, back-patch to all supported
 branches.
 
 Discussion: https://postgr.es/m/15865-17940eacc8f8b081@postgresql.org