Adjust handling of an ANYARRAY actual input for an ANYARRAY argument.

Ordinarily it's impossible for an actual input of a function to have
declared type ANYARRAY, since we'd resolve that to a concrete array
type before doing argument type resolution for the function.  But an
exception arises for functions applied to certain columns of pg_statistic
or pg_stats, since we abuse the "anyarray" pseudotype by using it to
declare those columns.  So parse_coerce.c has to deal with the case.

Previously we allowed an ANYARRAY actual input to match an ANYARRAY
polymorphic argument, but only if no other argument or result was
declared ANYELEMENT.  When that logic was written, those were the only
two polymorphic types, and I fear nobody thought carefully about how it
ought to extend to the other ones that came along later.  But actually
it was wrong even then, because if a function has two ANYARRAY
arguments, it should be able to expect that they have identical element
types, and we'd not be able to ensure that.

The correct generalization is that we can match an ANYARRAY actual input
to an ANYARRAY polymorphic argument only if no other argument or result
is of any polymorphic type, so that no promises are being made about
element type compatibility.  check_generic_type_consistency can't test
that condition, but it seems better anyway to accept such matches there
and then throw an error if needed in enforce_generic_type_consistency.
That way we can produce a specific error message rather than an
unintuitive "function does not exist" complaint.  (There's some risk
perhaps of getting new ambiguous-function complaints, but I think that
any set of functions for which that could happen would be ambiguous
against ordinary array columns as well.)  While we're at it, we can
improve the message that's produced in cases that the code did already
object to, as shown in the regression test changes.

Also, remove a similar test that got cargo-culted in for ANYRANGE;
there are no catalog columns of type ANYRANGE, and I hope we never
create any, so that's not needed.  (It was incomplete anyway.)

While here, update some comments and rearrange the code a bit in
preparation for upcoming additions of more polymorphic types.

In practical situations I believe this is just exchanging one error
message for another, hopefully better, one.  So it doesn't seem
needful to back-patch, even though the mistake is ancient.

Discussion: https://postgr.es/m/21569.1584314271@sss.pgh.pa.us

src/test/regress/expected/plpgsql.out

@@ -1789,7 +1789,7 @@ select f1(array[2,4]) as int, f1(array[4.5, 7.7]) as num;
 (1 row)
 
 select f1(stavalues1) from pg_statistic;  -- fail, can't infer element type
-ERROR:  argument declared anyarray is not an array but type anyarray
+ERROR:  cannot determine element type of "anyarray" argument
 drop function f1(x anyarray);
 create function f1(x anyarray) returns anyarray as $$
 begin

src/test/regress/expected/polymorphism.out

@@ -41,7 +41,7 @@ select polyf(array[2,4]) as int, polyf(array[4.5, 7.7]) as num;
 (1 row)
 
 select polyf(stavalues1) from pg_statistic;  -- fail, can't infer element type
-ERROR:  argument declared anyarray is not an array but type anyarray
+ERROR:  cannot determine element type of "anyarray" argument
 drop function polyf(x anyarray);
 create function polyf(x anyarray) returns anyarray as $$
   select x