Small reduction in memory usage of index relcache entries

While debugging an out-of-memory situation, I noticed that the relcache
entry of each index consumes 2k of memory. From a memory dump:

>...
> pg_database_datname_index: 2048 total in 1 blocks; 712 free (0 chunks); 1336 used
> pg_trigger_tgrelid_tgname_index: 2048 total in 1 blocks; 576 free (0 chunks); 1472 used
> pg_rewrite_rel_rulename_index: 2048 total in 1 blocks; 576 free (0 chunks); 1472 used
> pg_amproc_fam_proc_index: 2048 total in 1 blocks; 232 free (0 chunks); 1816 used
> pg_opclass_oid_index: 2048 total in 1 blocks; 664 free (0 chunks); 1384 used
> pg_index_indexrelid_index: 2048 total in 1 blocks; 664 free (0 chunks); 1384 used
> pg_attribute_relid_attnum_index: 2048 total in 1 blocks; 528 free (0 chunks); 1520 used
> pg_class_oid_index: 2048 total in 1 blocks; 664 free (0 chunks); 1384 used

Looking closer at where that memory is spent, a lot of it goes into the
FmgrInfo structs in RelationAmInfo. But some of them are outright unused
(ambuild, ambuildempty, amcostestimate, amoptions), and a few others
hardly are called so seldom that they hardly need to be cached
(ambuildelete, ambacuumcleanup). Removing those fields, patch attached,
reduces the memory usage nicely:

>...
> pg_database_datname_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
> pg_trigger_tgrelid_tgname_index: 1024 total in 1 blocks; 64 free (0 chunks); 960 used
> pg_rewrite_rel_rulename_index: 1024 total in 1 blocks; 64 free (0 chunks); 960 used
> pg_amproc_fam_proc_index: 3072 total in 2 blocks; 1736 free (2 chunks); 1336 used
> pg_opclass_oid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
> pg_index_indexrelid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
> pg_attribute_relid_attnum_index: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
> pg_class_oid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used

This brings most index entries from two 1k blocks down to one 1k block.
A backend seems to load about 60 indexes into the cache for system
tables, so that saves about ~60 kB of memory for every backend at a minimum.

This isn't a huge difference, unless you access a huge number of
indexes. But the patch is trivial, and every little helps. Any
objections if I commit this to master?

- Heikki