WIP: bitmap indexes

Hi all,

Attached is an update to the patch implementing bitmap indexes Jie sent
last week.

This patch tidies up some coding style issues, the system catalogs, adds
some basic docs and regression tests, as well as additional
functionality.

There are still outstanding bugs and problems. These are:

a) The planner doesn't really know about bitmaps. The code cheats. As
such, bitmap index access is not costed correctly.

b) There is, as Tom pointed out, a lot of code duplication around
BitmapHeapNext(), MultiExecBitmapIndexScan() and related routines. This
needs to be tidied up and would probably benefit from Tom's proposal to
change the behaviour of amgetmulti.

c) Related to this is the fact that the current on-disk bitmap cannot
handle the ScalarArrayOpExpr optimisation that normal bitmap scans can.
(The patch introduces some regression tests for bitmaps and one of these
fails with an invalid row count. This displays the problem that needs to
be solved).

d) Also related to this, in() subqueries are causing us to hit some
uninitialised memory. I haven't had time to explore this but it is related
to the architectural issue above.

e) Jie is hunting down a bug in multi-column support.

f) I haven't tested concurrency

I will continue to send in matches as we we make progress on these issues.
Feed back, in particular on (a) and (b), are most welcome.

Thanks,