Proposal: fix range queries in btree_gin

Hackers,

after reading Heikki Linnakangas presentation about GIN from Nordic PGDay,
I figure out that btree_gin became much more attractive.
http://hlinnaka.iki.fi/presentations/NordicPGDay2014-GIN.pdf

But it have one weird behaviour: when you have range restriction like "col
> const1 AND col < const2" it's handled as intersection of two separate
partial matches "col > const1" and "col < const2". So, it's awfully slow :(

The opclass can't handle it better because it only deals with "col >
const1" and "col < const2" separately. This two restrictions are
separately passed to gin_extract_query.

This problem is known, but now I can propose some solution.

We have range types, and restriction "col <@ range" can be correctly
handled by gin_extract_query, because it will be passed there as single
restriction. This is workaround itself, but it's weird to force users
express queries like this.

We can add some logic to gin. If it sees:
1) Query contain both "col > const1" and "col < const2" restrictions.
2) There is a range type for this type and comparison operator.
3) opclass supports "col <@ range"
then rewrite this two restrictions as "col <@ range(const1, const2)"

------
With best regards,
Alexander Korotkov.