XADataSource support for resource sharing & interleaving.

This reimplementation of the PGXADataSource (and supporting classes) provides more complete fulfillment of the JTA 1.0.1 specification.

It properly implements resource sharing (3.4.6) allowing all connections to the same underlying XAResource to control the global transactions created by other instances of that XAResource.

It addresses proper interleaving and isolation of local & global transaction scopes. (3.4.7)

The support for interleaving and sharing is implemented by returning 'logical' connections from the XADataSource, and opening new physical connections to the backend server (when necessary) to handle preforming work on behalf of a global TX or local TX.

The behavior of opening new physical backends (implementing interleaving) can be disabled by setting the XAAcquireTimeout = 0, in which case the behavior of the old XADataSource implementation is retained, with a minimal performance impact.

It tries hard to only open as many physical connections as necessary to service the logical connections, and prunes extraneous connections created as a result of supporting interleaving at each logical connection handle close().

In our production environment, where we have allocated our pool sizes to the actual observed in-use highwater mark + 30%, we are seeing zero connection churn, as there are enough free connections at any given time to properly service the checked-out, in-use logical connections and the interleaving & resource sharing being invoked by the container.

This implementation passes:
 * all the existing XADataSource test cases
 * the many we've added to test corner cases of XA handling in concurrent and pooled workloads.
 * the JBoss narayana Transaction Manager jdbc unit tests. (https://github.com/jbosstm/narayana)

In addition to the XADataSource changes
 * the build.xml has been update to respect (fully) the srcdir property
 * AbstractJdbc23PooledConnection exposes getBackingConnection() to sub-classes, allowing subclasses access to the underlying Connection object without needing to cache the instance in their constructors.

We have been successfully using this snapshot of code in our production environment (GlassFish 3.1.2.2) with PostgreSQL 9.1, and are pleased to report that it is working very well at this time.