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