This hidden bug cropped up while investigating different ways to
encode view descriptors.

This patch makes it possible to use the numeric table reference syntax
with a selection of columns (e.g. `[123(1,2,3)]`) when the reference
is for a view. This selects a subset of the view's definition.

… the query

Prior to this patch, a view defined with `CREATE VIEW v(x) FROM SELECT
y FROM ...` would only store the name "x" in the descriptor. This
would cause queries to pg_catalog or information_schema to hide the
fact the view renders a column named "x" (only showing "SELECT y
...").

This patch improves upon this situation by forcing an explicit rename
in the view query if the view definition changes the names.

This was the most glaring limitation of the previous approach, but in
addition to this a bug was lurking: a view created with `CREATE VIEW
v(rowid) FROM TABLE t`, which *intends* to reveal the `rowid` such
that subsequently `SELECT * FROM v` actually selects `rowid`, didn't
work as intended: when the view plan was expanded, the `rowid` column
would be picked from the underlying plan, which would make it hidden,
which would subsequently cause `SELECT * FROM v` to not pick any
column at all. The explicit rename approach taken in this patch fixes
this bug. This bug probably never affected anyone given how unlikely
the use case is, however fixing this fits the general effort of view
descriptor improvements this patch is part of.

For example:
```
> CREATE TABLE t.kv(k INT PRIMARY KEY, v INT);
> CREATE VIEW vx AS SELECT v AS x FROM t.kv;
> SHOW CREATE VIEW t.vx;
+------+-----------------------------------------------+
| View |                 CreateView                    |
+------+-----------------------------------------------+
| vx   | -- t.kv(k,v) = [71(1,2)]␤                     |
|      | CREATE VIEW vx (x) AS SELECT v AS x FROM t.kv |
+------+-----------------------------------------------+
(1 row)
```

i.e. the view query is unchanged but the view descriptor tracks the
mapping of names into the query to the actual IDs of the
dependencies. This information is reported in SHOW CREATE VIEW as a
SQL comment and in more details in
`crdb_internal.backward_dependencies`.

When the view query is loaded, this information in the view descriptor
overrides the regular name resolution path.