Bitmap AM relies on B-tree index code for all the operator support. In
fact, it creates an actual B-tree index, the LOV index, and lets the LOV
index evaluate the operators. We should have all the same operator classes
and families for bitmap index AM that we have for B-trees.

Perhaps we should teach the planner to reuse the B-tree opfamilies for
bitmap indexes. But for now, let's auto-generate the bitmap opfamiles at
initdb-time from the corresponding B-tree opfamilies. That ensures that the
two stay in sync, and we don't need to carry the diff vs. upstream in the
catalog headers.

This changes the OIDs for the opclasses and opfamilies, so bump catversion.
That shouldn't affect upgrade, or clients, though. They should operate on
opclass/opfamily names, not OIDs.

Some of the operators are still not indexable using bitmap indexes, because
they are handled by special code in the backend, see
match_special_index_operator(). But it doesn't do harm to have the entries
in the catalogs for them, anyway. An example of this is the inet << inet
operator and its siblings.

One user-visible effect of this is that you can now create a bitmap index
on the 'complex' datatype.

I did this now, because I was seeing 'opr_sanity' test failure on the 9.6
merge branch, because some cross-type operators were missing for bitmap
indexes. That was because the integer bitmap operator classes were not
gathered into the same operator family, they were still following the old
model, from before operator families were introduced. So there were
separate int2_ops, int4_ops, int8_ops operator families, whereas with the
B-tree, there's only one integer_ops operator family, which contains all
the opclasses and cross-type operators. I don't think it makes any
practical difference, though. For the B-tree, including all "compatible"
operators in the same opfamily allows the planner to deduce quals more
freely, but I'm not sure if that's significant for the bitmap AM, because
all the b-tree operators already exist.

Also change pg_am.amsupport for bitmap AM, to account for the new
'sortsupport' support function that was added to B-tree AM. I'm not sure
if bitmap indexes can actually make use of it yet, but we now copy all
the pg_amproc rows, so pg_am.amsupport better match or 'opr_sanity' test
complains.
Reviewed-by: NAshwin Agrawal <aagrawal@pivotal.io>