MODE-1822 Changed how transactional workspace caching is done

I identified a number of issues when working on this problem. The previous change to use a separate workspace cache for each transaction was not working correctly, because changes persisted (but not committed) in one `SessionCache` (e.g., the normal cache used within a JCR Session) would not be visible to other `SessionCache` instances (e.g., the one used by the JCR Session's version manager). Plus, because the workspace caches are specific to a single named workspace (including the hidden "system" workspace), changes in one workspace within one transaction were not visible to the other components participating in that transaction.

A `TransactionalWorkspaceCaches` class was created to manage the `TransactionalWorkspaceCache` instances used by the various session (and `SessionCache` instances) participating in a transaction. It keeps track of a single `TransactionalWorkspaceCache` for each named workspace used within each transaction. Additionally, all `TransactionalWorkspaceCache` instances within a transaction are thus notified when changes are persisted but not yet committed. As soon as the transaction is committed, the `TransactionalWorkspaceCache` for each workspace used in the transaction are all cleared, and the `AbstractSessionCache` instances are notified and changed. There also was additional wiring so that the `AbstractSessionCache` used by a JCR Session are all notified of any changes to other (temporary) SessionCaches.

Hopefully all of this infrastructure has very little effect on JCR Sessions that are not used within user transactions. About the only effect is that the JCR Session will check for a currently-running user transaction (which should be fast) upon `save()` and some workspace-write operations; otherwise, there should be no effect. Any time a JCR Session is created within a user transaction or used to save within a user transaction, that session knows about the transaction and uses the transactional workspace cache infrastructure; only when a session exists prior to the start of a user transaction does the checking for a current user transaction need to be done.

Several of the tests in `TransactionalTests` were modified, and several were added. Several other tests that started failing were examined, found to be incorrect, and then corrected.