WIP: Partial match using range key entries

While looking at the GIN's partial match logic, I got an idea to let the generic
index code do what opclass-specific comparePartial() functions do. It can be
achieved if range type is accepted as key entry.

In this patch I add ANYRANGEARRAY pseudotype (note that changes in
parse_coerce.c are rather ad hoc so far) and a set of cross-type operators like

ANYARRAY @> ANYRANGEARRAY

The semantics is that the range array is contained in the array iff each range
element has a matching (non-range) element in the left array. For example:

postgres=# SELECT ARRAY[-2, 5, 0.1, 10]::numeric[] @> ARRAY['[-10,-1]',
'[7,10]']::numrange[];
?column?
----------
t
(1 row)

postgres=# SELECT ARRAY[-2, 5, 0.1, 10]::numeric[] @> ARRAY['[-10,-1]',
'[7,10)']::numrange[];
?column?
----------
f
(1 row)

The other operators also correspond to those (ANYARRAY, ANYARRAY), except that
array elements are matched using
ANYRANGE @> ANYELEMENT

The patch just adds the matching logic to GIN. It does not remove the original
partial match because text search depends on it.

Subtopic: GIN and cross-type operators
--------------------------------------

So far all the in-core operators in the GIN's opfamilies have oprleft equal to
oprright. When I tried to implement the (ANYARRAY, ANYRANGEARRAY) operators I
had to do some changes in the core code:

1. While GIN_COMPARE_PROC and GIN_EXTRACTVALUE_PROC support functions depend on
pg_opclass(opckeytype) and pg_opclass(opcintype) respectively (and thus are
universial for the whole opclass), the other ones can be specific for
pg_amproc(amproclefttype, amprocrighttype). That's why I moved some code from
ginbeginscan() to ginrescan().

(I think it'd make sense to only store GIN_COMPARE_PROC and
GIN_EXTRACTVALUE_PROC once per opclass, but that would require changes in CREATE
OPERATOR CLASS command.)

2. To let the GIN code find the appropriate support functions for cross-type
operators, I had to ensure that scan key's sk_subtype contains OID of particular
type as opposed to that of the pseudotype.

Is there any misconception in this patch proposal?

// Antonin Houska (Tony)