pgsql: Ensure that typmod decoration on a datatype name is validated in

Log Message:
-----------
Ensure that typmod decoration on a datatype name is validated in all cases,
even in code paths where we don't pay any subsequent attention to the typmod
value. This seems needed in view of the fact that 8.3's generalized typmod
support will accept a lot of bogus syntax, such as "timestamp(foo)" or
"record(int, 42)" --- if we allow such things to pass without comment,
users will get confused. Per a recent example from Greg Stark.

To implement this in a way that's not very vulnerable to future
bugs-of-omission, refactor the API of parse_type.c's TypeName lookup routines
so that typmod validation is folded into the base lookup operation. Callers
can still choose not to receive the encoded typmod, but we'll check the
decoration anyway if it's present.

Modified Files:
--------------
pgsql/src/backend/access/common:
tupdesc.c (r1.120 -> r1.121)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/common/tupdesc.c?r1=1.120&r2=1.121)
pgsql/src/backend/commands:
aggregatecmds.c (r1.43 -> r1.44)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/aggregatecmds.c?r1=1.43&r2=1.44)
comment.c (r1.97 -> r1.98)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/comment.c?r1=1.97&r2=1.98)
functioncmds.c (r1.85 -> r1.86)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/functioncmds.c?r1=1.85&r2=1.86)
opclasscmds.c (r1.54 -> r1.55)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/opclasscmds.c?r1=1.54&r2=1.55)
operatorcmds.c (r1.36 -> r1.37)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/operatorcmds.c?r1=1.36&r2=1.37)
prepare.c (r1.77 -> r1.78)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/prepare.c?r1=1.77&r2=1.78)
tablecmds.c (r1.234 -> r1.235)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/tablecmds.c?r1=1.234&r2=1.235)
typecmds.c (r1.109 -> r1.110)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/typecmds.c?r1=1.109&r2=1.110)
pgsql/src/backend/parser:
parse_expr.c (r1.222 -> r1.223)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/parse_expr.c?r1=1.222&r2=1.223)
parse_func.c (r1.197 -> r1.198)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/parse_func.c?r1=1.197&r2=1.198)
parse_oper.c (r1.95 -> r1.96)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/parse_oper.c?r1=1.95&r2=1.96)
parse_relation.c (r1.128 -> r1.129)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/parse_relation.c?r1=1.128&r2=1.129)
parse_type.c (r1.91 -> r1.92)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/parse_type.c?r1=1.91&r2=1.92)
parse_utilcmd.c (r2.4 -> r2.5)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/parse_utilcmd.c?r1=2.4&r2=2.5)
pgsql/src/backend/utils/misc:
guc.c (r1.424 -> r1.425)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c?r1=1.424&r2=1.425)
pgsql/src/include/parser:
parse_type.h (r1.36 -> r1.37)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/parser/parse_type.h?r1=1.36&r2=1.37)
pgsql/src/pl/plpgsql/src:
pl_comp.c (r1.117 -> r1.118)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/pl_comp.c?r1=1.117&r2=1.118)