Preserve the SQL txn-aborted status.

Normally when an SQL command fails, the transaction is put into an
aborted state and all commands fail until ROLLBACK. PL functions,
however, operate in a sort of limbo: commands called through SPI will
not mark the transaction aborted, and this will only happen if the PL
function itself throws an SQL ERROR (which makes it all the way to the
top level). This means that a PL which uses PG_TRY without establishing
and rolling back a subtransaction needs to be very careful to disallow
all SPI access after a command has failed, and to ensure that the
function eventually throws an error of some sort.

In order to ensure this, I've introduced a new entry in the Lua registry
which records that this lua_State is in a should-be-aborted transaction.
All SPI-calling Lua functions check this entry and throw an error if it
is present, and if control returns to the Lua top-level without
rethrowing some sort of error the original error is rethrown. (Currently
this is just the message, as a new PL/Lua error, since I don't have an
ErrorData userdata yet.)

The aborted registry entry is removed at the point where we exit PL/Lua;
if we reenter it further up the call stack the exception will once again
be converted into a Lua exception, and cause the entry to be created
again. It's important to clear the abort in both the TRY and CATCH
branches, even though in the CATCH case we have a better error to
rethrow. If I do introduce subtxns, rolling back a subtxn will also need
to clear the abort status.

This commit also introduces a call to SPI_restore_connection after
PG_CATCH has caught an error. I'm not sure why this is necessary (the
function isn't documented), but without it the SPI connection state
appears to end up corrupted by the exception, the SPI_finish calls fail
claiming not to be connected, and if I ingore that failure I get
warnings about missing SPI_finish calls. Possibly this has something to
do with the implicit SPI_push done by the other SPI calls; in any case,
the other PLs all call this after PG_CATCH, so I assume it must be a
reasonable thing to do.
Change the format of Lua->SQL error conversion.

Put the real error message in the message part, and the 'this is a pllua
error' part in the detail. Otherwise the real error message tends to get
lost, as client libraries other PLs don't provide access to the detail
part of the error.

Also throw Lua-originated errors with a new made-up SQLSTATE of 'P0LUA'.
'P0' is the prefix for PL/pgSQL errors, so these should be handled
reasonably by code ignorant of PL/Lua, but it seems better than the
DATA_EXCEPTION code used previously.