pgsql: Rethink plpgsql's way of handling SPI execution during an

Log Message:
-----------
Rethink plpgsql's way of handling SPI execution during an exception block.
We don't really want to start a new SPI connection, just keep using the old
one; otherwise we have memory management problems as illustrated by
John Kennedy's bug report of today.  This requires a bit of a hack to
ensure the SPI stack state is properly restored, but then again what we
were doing before was a hack too, strictly speaking.  Add a regression
test to cover this case.

Modified Files:
--------------
    pgsql/src/backend/executor:
        spi.c (r1.131 -> r1.132)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/spi.c.diff?r1=1.131&r2=1.132)
    pgsql/src/include/executor:
        spi.h (r1.49 -> r1.50)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/executor/spi.h.diff?r1=1.49&r2=1.50)
    pgsql/src/pl/plpgsql/src:
        pl_exec.c (r1.120 -> r1.121)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/pl_exec.c.diff?r1=1.120&r2=1.121)
    pgsql/src/test/regress/expected:
        plpgsql.out (r1.21 -> r1.22)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/plpgsql.out.diff?r1=1.21&r2=1.22)
    pgsql/src/test/regress/sql:
        plpgsql.sql (r1.16 -> r1.17)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/plpgsql.sql.diff?r1=1.16&r2=1.17)