REINDEX filtering in the backend

Hi,

I had some spare time tonight so I started a prototype to allow
filtering the indexes that are processed using the REINDEX command, as
Peter suggested in the parallel reindexdb thread [1].

I didn't want to spend too much time enjoying bison and adding new
unreserved keywords, so for now I just implemented this syntax to
start a discussion for this feature in the next commitfest:

REINDEX ( FILTER = COLLATION ) [...]

The FILTER clause can be used multiple times, each one is OR-ed with
the ReindexStmt's option, so we could easily add a LIBC, ICU and other
filters, also making COLLATION (or more realistically a better new
keyword) an alias for (LIBC | ICU) for instance.

The filtering is done at table level (with and without the
concurrently option), so SCHEMA, DATABASE and SYSTEM automatically
benefit from it. If this clause is used with a REINDEX INDEX, the
statement errors out, as I don't see a valid use case for providing a
single index name and asking to possibly filter it at the same time.

Under the hood, the filtering is for now done in a single function by
appending elements, not removing them. An empty oid list is created,
all indexes belonging to the underlying relation are processed by the
specific filter(s), and any index that fails to be discarded by at
least one filter, even partially, is added to the final list.

I also added some minimal documentation and regression tests. I'll
add this patch to the next commitfest.

[1] https://www.postgresql.org/message-id/7140716c-679e-a0b9-a273-b201329d8891%402ndquadrant.com