sql: stricter type checking than PG when creating routine with output parameters

Here is an example of what works in PG:
```sql
CREATE FUNCTION f(OUT sum INT, INOUT a INT, INOUT b INT) LANGUAGE SQL AS $$ SELECT (a + b, b); $$;
```
Note that we said that `f` would return a record with 3 columns but only returned 2. If the result is not used as the data source, invoking this function succeeds in PG:
```
yuzefovich=# SELECT f(1, 2);
f
-------
(3,2)
...
yuzefovich=# SELECT * FROM f(1, 2);
ERROR: 42804: function return row and query-specified return row do not match
DETAIL: Returned row contains 2 attributes, but query expects 3.
LOCATION: tupledesc_match, execSRF.c:955
```
We prohibit creation of such UDF in the first place.

AFAICT postgres allows routines to return a record with different number of columns than what we get based on the output parameters. The only restriction is that the return value must at have at least 2 columns and that the definition effectively has `RETURNS RECORD`.

For procedures the behavior of PG is more permissive as well:
```
yuzefovich=# CREATE PROCEDURE p(OUT sum INT, INOUT a INT, INOUT b INT) LANGUAGE SQL AS $$ SELECT (a + b, b); $$;
CREATE PROCEDURE
yuzefovich=# CALL p(NULL, 1, 2);
sum | a | b
-----+---+---
3 | 2 |
...
yuzefovich=# CREATE OR REPLACE PROCEDURE p(OUT sum INT, INOUT a INT, INOUT b INT) LANGUAGE SQL AS $$ SELECT (a + b, b, a, b); $$;
CREATE PROCEDURE
yuzefovich=# CALL p(NULL, 1, 2);
sum | a | b
-----+---+---
3 | 2 | 1
```

Jira issue: CRDB-37169

Start by reproducing the supplied CREATE FUNCTION and CREATE PROCEDURE examples in CockroachDB and PostgreSQL, comparing creation and invocation behavior. The issue names no source files or tests, so trace the SQL routine output-parameter type-checking path from the failing reproduction. Done means the supported behavior matches the intended PostgreSQL compatibility for these cases.

Written by the indexing model from the issue text.