Bitmapscan changes

Here's a patch to change the amgetmulti API so that it's called only
once per scan, and the indexam adds *all* matching tuples at once to a
caller-supplied TIDBitmap. Per Tom's proposal in July 2006:
http://archives.postgresql.org/pgsql-hackers/2006-07/msg01233.php

The patch also adds support for candidate matches. An index scan can
indicate that the tuples it's returning are candidates, and the executor
will recheck the original scan quals of any candidate matches when the
tuple is fetched from heap. The candidate status is tracked in TIDBitmap
on a per-page basis.

No current indexams return candidate matches, but they can (and are with
the patch) also be used when bitmap ANDing a lossy and non-lossy page:
the result is a non-lossy candidate page, containing the bits of the
non-lossy page.

The motivation for adding the support for candidate matches is that GIT
/ clustered indexes need it. It's likely that we'll modify the API
further to add support for the stream bitmaps when the bitmap indexam
patch moves forward, but this is a step in the right direction and
provides some immediate benefit.

I added some regression tests to test bitmap AND and OR with a mixture
of lossy and non-lossy pages, and to test the GIN getbitmap function
which wasn't being exercised by any existing the regression tests.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com