Adding a typmod field to Const et al

A month or so back I wrote:
> BTW, I think a good case could be made that the core of the problem
> is exactly that struct Const doesn't carry typmod, and thus that we
> lose information about constructs like 'foo'::char(7). We should fix
> that, and also anywhere else in the expression tree structure where
> we are discarding knowledge about the typmod of a result. This has
> got some urgency because of Teodor's recent work on allowing user
> defined types to have typmods --- we can expect massive growth in the
> number of scenarios where it matters.

I looked into this and determined that the interesting cases seem to be

Const: needs a struct field added

ArrayRef: ditto; but we could drop refrestype which is
redundant

SubLink: EXPR and ARRAY cases should recurse to
subplan target item, as exprType() does

ArrayExpr: should adopt the same behavior as Coalesce and
similar nodes, ie, if all the elements show the
same type/typmod then return that typmod
instead of -1

With these changes, exprTypmod covers all the same cases as exprType,
except for cases that demonstrably don't have a typmod, such as the
result of a non-length-coercion function, or nodes that have a hardwired
result type such as BOOL that doesn't take a typmod.

Comments, objections?

regards, tom lane