merging some features from plpgsql2 project

Hi

I reread ideas described on page https://github.com/trustly/plpgsql2

Some points are well and can be benefit for PlpgSQL.

First I describe my initial position. I am strongly against introduction
"new" language - plpgsql2 or new plpgsql, or any else. The trust of
developers to us is important and introduction of any not compatible or
different feature has to have really big reason. PostgreSQL is conservative
environment, and PLpgSQL should not be a exception. More - I have not any
information from my customers, colleagues about missing features in this
language. If there is some gaps, then it is in outer environment - IDE,
deployment, testing,

I understand so we have to do some break compatibility changes, but the
changes should be smoothly with possibility to simply identify necessary
changes, but better don't do it - and use other possibility.

i lost hope so plpgsql_check can be integrated to core. It is living
outside well - only preparing dll for MSWindows is annoyance. But some
checks from plpgsql_check can be implemented in core as extra_checks, and
some checks from plpgsql2 can be implemented in plpgsql_check.

Points from plpgsql2:
* SELECT .. INTO vs. TOO_MANY_ROWS - can be implemented as extra check
* SELECT .. INTO and the number of result columns - good extra check too

* EXECUTE and FOUND - this is incompatible change, extra check can be used
(test on unset variable). I see solution in leaving FOUND variable and
introduction of some new without this issue - ROW_COUNT maybe (this is
another possible incompatible change, but with higher benefit - maybe we
can introduce some aliasing, PRAGMA clause, default PRAGMAs, ..).

* SELECT .. INTO and := - looks bizarre, but I see clean benefit and I can
accept it

* The OUT namespace and OUT parameter visibility - I don't like it - not in
this form - can we introduce some form of namespace aliasing? The arguments
are in function name named namespace already.

Now, we doesn't use plpgsql_extra_check much and it is pity.

I thing so real question is support some macros, that can help with code
maintenance for different PostgreSQL versions. PostGIS code is nice example
what we are missing.

Regards

Pavel