Planned changes to pg_am catalog

Since I am about to add a "bulk delete" routine to the index access
method APIs for concurrent VACUUM, I need to add a column to pg_am
to define the associated procedure for each index AM.  This seems like
a fine time to clean up some of the other outstanding TODO items for
pg_am:

1. Add boolean columns that indicate the following for each AM:* Does it support UNIQUE indexes?* Does it support
multicolumnindexes?* Does it handle its own locking (as opposed to expecting  the executor to obtain an index-wide
lock)?
This will eliminate ugly hardcoded tests on index AM oid's in various
places.

2. Remove the "deprecated" columns, which aren't doing anything except
wasting space.

3. Alter the index_build code so that we don't have duplicate code in
each index AM for scanning the parent relation.  I'm envisioning that
index.c would provide a routine IndexBuildHeapScan() that does the basic
heap scan, testing of partial-index predicate, etc, and the calls back
an index-AM-specific routine (which it's handed as a function pointer)
for each tuple that should be added to the index.  A void pointer would
also be passed through to let the callback routine have access to
working state of the AM-specific index_build procedure.
(IndexBuildHeapScan would replace the currently-unused DefaultBuild
routine in index.c, which is mostly the same code it needs anyway.)
The index AM's index_build procedure would do initial setup, call
IndexBuildHeapScan, and then do any finishing-up processing needed.


Note that this doesn't address Oleg's concerns about haskeytype,
lossiness, etc.  AFAICS those issues are not related to the contents
of pg_am.  Later on, I am going to have some proposals for altering
pg_opclass and related tables to deal with those issues...

Comments?  Any other festering problems in this immediate area?
        regards, tom lane