[PG19] Bogus errors for polymorphic plpython functions

PL/Python doesn't make any effort to support polymorphic arguments
or results. (It should, but that's a task for some other day.)
However, I happened to notice that while previous releases throw
a useful error:

regression=# CREATE FUNCTION python_poly(x anyelement) RETURNS anyelement AS $$
return x
$$ LANGUAGE plpython3u;
ERROR: PL/Python functions cannot return type anyelement

in v19/master you get something pretty off-point:

regression=# CREATE FUNCTION python_poly(x anyelement) RETURNS anyelement AS $$
return x
$$ LANGUAGE plpython3u;
ERROR: could not determine actual result type for function "python_poly" declared to return type anyelement

The reason for this is that commit 9bcb8a694 restructured things
to let plpython use the funccache.c infrastructure. That means
that the argument-type checks done in PLy_procedure_create are
now inside a callback function that funccache.c calls after it's
discovered it lacks a cache entry for the function. And in order
to lookup a cache entry, it has to resolve polymorphic types to
real types, and the fake fcinfo that plpython3_validator makes
doesn't contain enough data to support that.

I don't want to resolve that conundrum right now --- for one thing,
I've not made up my mind whether it's more plpython's fault or
more funccache.c's fault. What I think we should do about this
is to move the no-pseudotype-argument checks from where they are
into the validator's startup section, where they will get enforced
whether check_function_bodies is on or not. (It's really a bug that
right now you don't hear about this if !check_function_bodies.)
In that way, they'll happen before funccache.c is asked to do
anything, so we don't encounter the underlying problem. Even when
we do resolve the problem on the way to fixing plpython to support
polymorphics, this is a better code structure: it reports errors
sooner and takes some catalog lookups out of the normal function
call path.

Comments?

regards, tom lane