use radix tree for bitmap heap scan

This is not in reviewable state, but I wanted to get a sketch of a PoC
out there and highlight some issues that will need to be tackled. The
index scan successfully populates the radix tree and the contents are
verified to match the hash table for the queries present in the
regression tests. (Now that I think of it, this patch set might not be
buildable as is, since my local tree has two copies of the radix tree
template so TID store doesn't break while working on this)

First issue: Different memory management needs from vacuum. I split
RT_SET into two functions, the lower of which is similar to simple
hash's "insert" method.

Second issue: TBM intersection
1) Radix tree iteration assumes that no one will delete keys out from
under it. That includes the caller itself! This is not sufficient for
intersecting bitmaps. I kluged around it by saving
blocks-to-be-deleted in a stack array, but a proper solution could be
to (vigorous handwaving)
1) save per-leaf-node keys in the iterator
2) delete the keys when iteration leaves that node, possibly with a
bulk-delete mechanism
3) restart iteration from the top, at the next part of the key space

The above is enough to get rid of the qsort call, but next we'll want
to use variable-length bitmaps like vacuum does. This is both to
reduce memory use and to allow the length of the line pointer array to
be sized independently from MaxHeapTuplesPerPage. That will require
getting rid of the iterator array and doing shared iteration over the
tree itself. Ideally, this will be done in a way compatible with
vacuum, but resolving the differences into new abstractions will be
the final step.

--
John Naylor
Amazon Web Services