Remove/fix the need for using Jackrabbit XAResource based wrappers

Jackrabbit supports using XAResource based UserTransactions, and by default always creates a XASession enabling this.

We however never use this 'feature' but it wraps and decorates most of the JR core/state managers, with XASession, XALockManager, XAItemStateManager, etc.

Dropping that extra and unnecessary wrapping and decorating, including the need to support the XA interfaces in our own extension however isn't possible right now because the Jackrabbit implementations in the XA* classes started to deviate from their core classes, even if/when they simply should delegate to the core classes when not executing in an XA transation scope.

One example of this is the Jackrabbit XALockManager#isLocked(NodeImpl) method which is the following:

public boolean isLocked(NodeImpl node) throws RepositoryException {
        LockInfo info;
        if (isInXA()) {
            info = xaEnv.getLockInfo(node);
        } else {
            info = lockMgr.getLockInfo(node.getNodeId());
        }
        return info != null;
    }

while the core implementation in LockManagerImpl (which XALockManager extends) is different (not directly delegating to LockMgr.getLockInfo(NodeId)) and leading to different results if/when it would be used!
This surfaced when trying to execute the Jackrabbit tests using plain/non-XA based SessionImpl instead of XASession session instances.
In casu: the jackrabbit-jcr-tests LockTest#testMoveLocked() will fail because of this.
Root cause after deep investigation: the changes introduced by the fix/patch for https://issues.apache.org/jira/browse/JCR-1633 (2009!)
And 'fixing' this isn't trivial either: the actual/technical difference is really subtle (which session will see not-yet-persistent changes) and the result of different expectations/interpretations in context of an XA transaction. So it is even debatable which implementation should be followed or is to be considered correct.  

While this is just one example, it is likely there are (many) more deviations between XA* classes from their core classes, simply because in Jackrabbit every session always is setup using the XA* classes. So all tests and production hardenings are based upon and assume this context, regardless if XA transactions are used or not.

Before we safely can drop using the XA* class wrappers we thus will and must inspect and verify each and every one of these wrappers to fix such deviations, within Jackrabbit. And that will be a huge undertaking, possible even require extensive discussions with the Jackrabbit project itself in case of debatable needed fixes upstream.