Fix some issues with transaction handling when calling stored procedures

Several closely related problems:
* If there is an error, a transaction can be left open on the session, but not associated with the PG connection and so impossible to get rid of.
* If a routine opens a JDBC connection and does not close it (or return result sets in auto-commit mode), it can be stuck in the same way.
* If a routine calls a nested routine that returns a result set and then another routine, that second one needs to use the same transaction as is needed to read from the result set. At least so long as we stick to the rule of only one transaction per top-level session at a time.

To accomplish this, track JDBC contexts in the call stack thread local and give them a chance to close things and/or issue warnings as the stack is popped. The rough idea is that popping back the PG context should not leave a transaction that wasn't started there open.

See new YAML tests for interesting cases and samples of the warnings that appear in PSQL if you call a procedure with leaks.

Also need to fix Direct, which wasn't prepared to deal with one procedure calling another at all. Although very few things use it, you do always get one of its contexts when calling a routine.