RFD: Don't force plpgsql IN parameters to constant

Is there a reason we force plpgsql IN parameters to constant? The
reason I ask is because having them mutable would go a long way in
easing a port from Informix's SPL. For better or worse, we have a fair
amount of code in SPL that does something like:

    -- pObjectId is an IN parameter
    IF pObjectId IS NULL THEN
        pObjectId := newid();
    END IF;

I understand it may be better to use a different technique here, but
we have a substantial amount of SPL (40k lines) and if we could make
the IN parameters mutable, it would make my day.

Looking at the history of the code, it looks like this has been the
way it has been since the beginning. Tom added a comment in 1995
asking why we force the IN parameters to constant, but the "why?" part
of the comment was removed in a later change to support OUT and INOUT
parameters.

I've attached a patch that would change this behavior. Also, the
test2(int) function below works with the patch, but would fail to
compile without. I also checked to make sure the parameter wasn't
passed by reference and it is not. The test at the bottom returns 't'
meaning test2(int) did not change the a variable in test1().

CREATE OR REPLACE FUNCTION test1() RETURNS INT AS $$
DECLARE
     a INT;
BEGIN
     a := 1;
     PERFORM test2(a);
     RETURN a;
END
$$ LANGUAGE plpgsql;

CREATE OR REPLACE FUNCTION test2(a INT) RETURNS VOID AS $$
BEGIN
     a := 2;
END
$$ LANGUAGE plpgsql;

SELECT test1() = 1;

If this change would be acceptable, I'll proceed in finishing the
patch by updating docs and adding regression tests.

-Steve