Memory leak in gingetbitmap

While looking at the segfault that Olaf Gawenda reported (bug #12694), I 
realized that the GIN fast scan patch introduced a small memory leak to 
re-scanning a GIN index. In a nutshell, freeScanKeys() needs to pfree() 
the two new arrays, requiredEntries and additionalEntries.

After fixing that, I'm still seeing a small leak. I found that the 
queryCategories field also needs to be free'd, but it still leaks even 
after fixing that.

I think we need a more whole-sale approach. I'm thinking of adding a new 
memory context to contain everything related to the scan keys, which can 
then be destroyed in whole.

We haven't heard any complaints about this from users, but I think this 
deserves to be fixed. Perhaps not worth back-patching however.

PS. Here's what I'm using to test this:

create extension btree_gin;
create table a (t text);
create table b (t text);
insert into b values ('foo'), ('bar');
insert into a select 'x'||g from generate_series(1, 2000000) g;
create index i_b On b using gin (t) ;
set enable_hashjoin=off;
set enable_material=off;
set enable_seqscan=off;
set enable_mergejoin=off;
set enable_indexscan=off;

select * from a, b where a.t = b.t;

It doesn't leak if the index is a regular b-tree index.

- Heikki