ISPN-2639 Initial JSR 107 implementation

* Basic operations and validation supported.
ISPN-2639 Integrate JCache 0.6 version and integrate TCK testing

* Use Maven Invoker Plugin to run TCK automatically in each build.
avoid leaking classloaders.
* Cache manager name for Infinispan JMX configuration should be
composed of the cache manager name and classloader information in
order to guarantee uniqueness. Otherwise, TCK fails with a lot of
JMX domain conflict errors, and there's no real reason for allowing
duplicate domains whose name would be more confusing.
* Infinispan cache manager implementation has a finalize() method to
avoid cache managers being garbage collected without proper shutdown.
* Move to a weak key map for cache manager collections, keyed on
class loader that avoids leaks.
* Make all other references to class loaders weak to avoid keeping
strong references.
* Implement support for UserTransaction
* Use jcache as module name
* Added support for Cache writers.
* Add an assertion to Infinispan Cache so that old values are checked
for null.
* Implement removeAll().
* Some operations should skip loading from cache.
* If cache non transactional, return STATUS_NO_TRANSACTION.
ISPN-2767 Add defensive copying option for storeAsBinary functionality

* This enables true, store-as-value, functionality within Infinispan.
* It's required by the JSR-107 specification.
ISPN-2824 Add support for JSR-107 Cache.invokeEntryProcessor()

* It uses an optimistic method based around reference copying and
conditional, CAS-like, cache operations to provide perceived exclusive
data access.
* It also adds per-key locking for when keys are used by the entry
processor in order to necessary delays to operations.
* To avoid affecting performance of normal CRUD cache operations,
it checks whether a key is locked before trying to acquire the lock
for it. If it's locked, it means it's in use by an entry processor.
ISPN-2766 Adapt JSR-107 notification model to Infinispan's listeners

* CacheEntryCreatedEvent.getValue() was added to be able to get a
callback with the new value created.
* CacheEntryModifiedEvent.isCreated() added to differentiate between
modified events as a result of entry created, versus entry updated.
* CacheEntryRemovedEvent.getOldValue() added so that the old value
can be queried when isPre=false.
* Skip listener flag created to have finer grained control over
which cache methods should fire events. This is necessary in order
to pass the strict callback tests in the TCK.
ISPN-2856 Implement support for JSR-107 expired entry notification

* Use an interceptor to detect when an entry is expired, and based
on that send the notification to any registered listeners.
ISPN-2639 Keep CDI module using JCache 0.4 and fix classloader weak ref

* Keep JSR-107 annotations using 0.4 until issue has been solved.
This will be addressed as part of ISPN-2855.
* Fix issues with classloader weak references.
* Implement missing methods in listener event adapter implementations
in the CDI module.
ISPN-2959 Improve the release scripts
- Only bump version if releasing a Final and also commit version bump on the branch being released
- Make some parts of the scripts less specialized so that it can be used for Infinispan Server
ISPN-2936 Move REST Server cache manager to ServletContext

Moved cache manager to ServletContext, added TwoServerTest.
ISPN-2962 Fix thread leaks in the core test suite

* Several tests do not shutdown their Executors or fail to stop an AsyncStore (notably AsyncStoreTest and AsyncStoreStressTest), leading to stray threads after the suite is run.
* DistributedExecutorTest and ReplSyncDistributedExecutorTest ocasionally swallow an interrupt preventing the pooled thread to stop when it is returned back to the pool and tries to take() the next task to execute.
* Print all the threads at the end of the test suite that were not already present at the beginning. These are leak suspects.
ISPN-2477 AsyncStore shutdown can leak threads

Partially solves ISPN-2477
* There were two exit points in the AsyncStoreCoordinator loop, and only one of them stopped the worker thread pool.
* AsyncStoreCoordinator must force the worker threads to shut down via interrupt if the initial attempt to shutdown the executor pool did not finish in time and some workers might still be running.