pg_stat_statements: simplify SQL API version tracking

Hi,

While working on the pg_stat_statements scalability patch set [1], I
found that every new pg_stat_statements SQL API version requires
recording its number of output columns in several places. A
PG_STAT_STATEMENTS_COLS_V1_x #define, a case in the switch in
pg_stat_statements_internal() that validates the result descriptor,
and a line in the Assert at the end of the same function that checks
the number of columns filled. On top of that, each version gets its
own hand-written wrapper function, identical to the others except for
the version passed in.

A new SQL API version is not common, roughly once a release in recent
years, but each one adds another copy of the same code. The switch is
now at 10 cases and there are 8 near-identical wrappers, and this
keeps growing with every new version.

The attached patch replaces all of this with a single array, indexed
by pgssVersion:

```
static const int pgss_api_cols[] =
{
[PGSS_V1_0] = 14,
[PGSS_V1_1] = 18,
...
[PGSS_V1_13] = 54,
};
```

which is used by both the descriptor check and the final Assert. The
1.0/1.1 special case for the legacy entry point is kept. The wrappers,
along with their PG_FUNCTION_INFO_V1 declarations, are now generated
with a macro, as done in pgstatfuncs.c and btree_gin. The function
names are passed to the macro as-is, so they can still be found with
grep, though ctags will no longer index them. That is not a big deal
for these trivial functions, which just call pg_stat_statements_internal().

A static assertion checks the size of the array against a new
PGSS_NUM_VERSIONS, so they cannot get out of sync without a compile
failure. Today, forgetting a case in the switch is only caught at
runtime.

Overall, this is less code. The patch removes about 100 lines, and
future versions no longer add copies of the same code. It is a
refactoring, with no behavior changes. It also adds an Assert that a
version's number of columns fits in values[] before anything is
written, which the current code does not check.

Is this worth doing?

While testing, I noticed that "incorrect number of output arguments"
is not covered by any regression test. I did not include it yet, but
perhaps it's worthwhile?

[1] https://www.postgresql.org/message-id/flat/CAA5RZ0sQ+gDn-J85j1FzOdL1YjVYRegpmQpDiah1=REWZSZj+Q(at)mail(dot)gmail(dot)com

--
Sami Imseih
Amazon Web Services (AWS)