Mark internal_in as not strict, so that the construct "null::internal"

will throw an error, rather than possibly allowing someone to synthesize
a manual call to an internal-accepting function.  As of CVS HEAD and existing
releases, all such functions are either STRICT or careful about null inputs,
so there is no current security issue here.  But it seems like a good idea
to lock this down to protect against future mistakes.

In passing, similarly lock down trigger_in, language_handler_in, opaque_in,
and shell_in.  These are not believed to present any security risk, but
there's still no good reason to allow nulls of these types to be created.
I left the polymorphic pseudotypes (anyelement etc) alone, since a null
of one of those types doesn't seem to be a problem --- the worst you can
say about it is that it doesn't have an underlying non-polymorphic type.

If we were to make this change during normal development, we'd just
automatically bump catversion for a pg_proc.h change.  But since this doesn't
create a compatibility risk and isn't believed to be fixing a live bug, it
seems better not to force a catversion bump in late beta.