ALTER FUNCTION / STRICT

This patch allows ALTER FUNCTION set change a function's strictness. In
and of itself this isn't very useful, but it is defined in SQL2003, so
it's probably worth implementing.

Notes:

- the optimizer considers strictness; for example, the optimizer will
pre-evaluate calls to a strict function that is passed NULL (i.e.
replacing the function call with a NULL). This means if you create a
function, create a plan that calls the function, change the function's
strictness, and then invoke the stored plan, the function's old
strictness will still apply. Considering we have rather more serious
problems involving out-of-date plans following DDL, I don't think this
is a big deal, but I thought I'd mention it.

- SQL *requires* a "CASCADE" keyword following the ALTER command. I made
it optional, but even optional it's a little ugly.

- I considered making it possible to change other attributes of a
function (e.g. volatility and security definer), and the patch is
implemented such that this should be easy to do. Does anyone think this
is worth doing? (The same kinds of not-flushing-dependent-objects on
ALTER issues apply as with strictness and saved plans.)

- SQL also specifies that the LANGUAGE clause of the function definition
should be modifiable, but that strikes me as quite bizarre. The other
things SQL defines for ALTER FUNCTION don't have equivalents in PG
(<parameter style clause>, <SQL-data access indication>, <dynamic result
sets characteristic>, and NAME <external routine name>).

Incidentally, is there a reason that DROP FUNCTION doesn't use the
FuncWithArgs node? Given that the latter exists, ISTM we may as well use
it where applicable.

-Neil