This commit adds the GPDB side changes required to support GIN Indexes with
ORCA.  It also adds a new test file gp_gin_indexes to test plans produced for
ORCA/planner.

GIN indexes are not supported with index expression or predicate constraints.
ORCA does not support it currently for other types of indexes too.

It was only needed for EState. builtins.h is included from many different
places, so it seems good to not pull in executor.h. Add explicit #includes
into many places that were relying on the indirectly included executor.h.

bms_next_member() is added in 9.5. Might as well backport that now, to
eliminate the redundant bms_first_from().

In the passing, revert a couple of spurious GPDB differences vs upstream:

* Resurrect the rightmost_one_pos lookup table. I'm not sure why that was
  done differently, but presumably the lookup table is faster, and that's
  what upstream uses anyway.

* Use plain / and % in WORDNUM and BITNUM macros. The compiler will surely
  turn them into the equivalent CPU instructions, using >> and &.

Prior to this commit, there was no support for GiST indexes in GPORCA.
For queries involving GiST indexes, ORCA was selecting Table Scan paths
as the optimal plan. These plans could take up to 300+ times longer than
Planner, which generated a index scan plan using the GiST index.

Example:
```
CREATE TABLE gist_tbl (a int, p polygon);
CREATE TABLE gist_tbl2 (b int, p polygon);
CREATE INDEX poly_index ON gist_tbl USING gist(p);

INSERT INTO gist_tbl SELECT i, polygon(box(point(i, i+2),point(i+4,
i+6))) FROM generate_series(1,50000)i;
INSERT INTO gist_tbl2 SELECT i, polygon(box(point(i+1, i+3),point(i+5,
i+7))) FROM generate_series(1,50000)i;

ANALYZE;
```
With the query `SELECT count(*) FROM gist_tbl, gist_tbl2 WHERE
gist_tbl.p <@ gist_tbl2.p;`, we see a performance increase with the
support of GiST.

Before:
```
EXPLAIN SELECT count(*) FROM gist_tbl, gist_tbl2 WHERE gist_tbl.p <@ gist_tbl2.p;
                                                     QUERY PLAN
---------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=0.00..171401912.12 rows=1 width=8)
   ->  Gather Motion 3:1  (slice2; segments: 3)  (cost=0.00..171401912.12 rows=1 width=8)
         ->  Aggregate  (cost=0.00..171401912.12 rows=1 width=8)
               ->  Nested Loop  (cost=0.00..171401912.12 rows=335499869 width=1)
                     Join Filter: gist_tbl.p <@ gist_tbl2.p
                     ->  Table Scan on gist_tbl2  (cost=0.00..432.25 rows=16776 width=101)
                     ->  Materialize  (cost=0.00..530.81 rows=49997 width=101)
                           ->  Broadcast Motion 3:3  (slice1; segments: 3)  (cost=0.00..525.76 rows=49997 width=101)
                                 ->  Table Scan on gist_tbl  (cost=0.00..432.24 rows=16666 width=101)
 Optimizer status: PQO version 2.65.1
(10 rows)

Time: 170.172 ms
SELECT count(*) FROM gist_tbl, gist_tbl2 WHERE gist_tbl.p <@ gist_tbl2.p;
 count
-------
 49999
(1 row)

Time: 546028.227 ms
```

After:
```
EXPLAIN SELECT count(*) FROM gist_tbl, gist_tbl2 WHERE gist_tbl.p <@ gist_tbl2.p;
                                                  QUERY PLAN
---------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=0.00..21749053.24 rows=1 width=8)
   ->  Gather Motion 3:1  (slice2; segments: 3)  (cost=0.00..21749053.24 rows=1 width=8)
         ->  Aggregate  (cost=0.00..21749053.24 rows=1 width=8)
               ->  Nested Loop  (cost=0.00..21749053.24 rows=335499869 width=1)
                     Join Filter: true
                     ->  Broadcast Motion 3:3  (slice1; segments: 3)  (cost=0.00..526.39 rows=50328 width=101)
                           ->  Table Scan on gist_tbl2  (cost=0.00..432.25 rows=16776 width=101)
                     ->  Bitmap Table Scan on gist_tbl  (cost=0.00..21746725.48 rows=6667 width=1)
                           Recheck Cond: gist_tbl.p <@ gist_tbl2.p
                           ->  Bitmap Index Scan on poly_index  (cost=0.00..0.00 rows=0 width=0)
                                 Index Cond: gist_tbl.p <@ gist_tbl2.p
 Optimizer status: PQO version 2.65.1
(12 rows)

Time: 617.489 ms

SELECT count(*) FROM gist_tbl, gist_tbl2 WHERE gist_tbl.p <@ gist_tbl2.p;
 count
-------
 49999
(1 row)

Time: 7779.198 ms
```

GiST support was implemented by sending over GiST index information to
GPORCA in the metadata using a new index enum specifically for GiST.
Signed-off-by: NBhuvnesh Chaudhary <bchaudhary@pivotal.io>
Signed-off-by: NEkta Khanna <ekhanna@pivotal.io>

We seemed to be doing that in this case.  This was caught by enabling
memory_protect_buffer_pool GUC.

Fix invalid reference to relcache entries.

After a relation is closed, the relcache entry
might be freed if its refcount goes to zero and we
should avoid further reference to it.

This is a fix to already existing bug and current
tests can cover the code changes here. So there is
no need to add new test case.

They were not kept up-to-date anymore anyway. Remove the actual tables.

There are still a few references to these tables in the management tools.
AFAICS they're in tests, and I was hesitent to remove them just yet, in
case we're going to use the existing tests as a guide when writing new
tests.

This bumps the copyright years to the appropriate years after not
having been updated for some time.  Also reformats existing code
headers to match the upstream style to ensure consistency.

They don't exist in the upstream. All but one of the callers actually just
needed list_member_*().

This fixes up whitespace and formatting issues in the code touched
by the last new commits. Separated into a single commit for easier
diff reading of the actual code changes.

Improves defensiveness of programming around pointer derefencing to
ensure that we don't risk a NULL pointer. Most of these are quite
straight-forward, those of note are discussed below.

In doDispatchDtxProtocolCommand() we relied on the result data being
created in zeroed out memory on CdbDispatchDtxProtocolCommand() which
isn't guaranteed for every compiler. Explcitly set numResults to zero
and also check the results for NULL.

Per multiple reports by Coverity

The IndexInfo structs are used by ORCA to decide which indexes match an
expression, and there may be some other similar use for them too. This patch
changes it to fetch the index expressions and predicates from the relcache,
rather than deparsing them directly from the pg_index catalog. The versions
stored in the relcache have been run through const-evaluation and
canonicalization passes, so they are slightly different. I believe the
versions stored in the relcache are what we actually want here, for the
reasons explained in RelationGetIndexPredicate() and
RelationGetIndexExpressions().

We always passed CurrentMemoryContext for them, so might as well remove
the parameter, making the code more readable, and always allocate the
return values in CurrentMemoryContext.

The real ones are in parse_expr.h and makefuncs.h.