MODE-1830 Corrected the purging of workspace caches in a cluster

Before this fix, when a change was made via a WritableSessionCache,
any changes persisted to the store were also used to directly purge
any previously-cached node representations from the corresponding
WorkspaceCache. Thus, when the RepositoryCache received the changes,
it simply forwarding them to all workspaces except the one in which
the changes originated.

However, in a clustered environment, the changes originate on one
process and are sent to all other processes. The logic described
above works fine in the same process in which the changes originated,
but it doesn't correctly propagate the changes in the other processes.

The fix was pretty simple: determine if the changes came from the same
process. If so, the use the current logic. If not, always forward the
changes to all WorkspaceCache instances.

I also modified the ClusteredRepositoryTest to look in process A for
nodes changed in process B. This failed before the logic was fixed,
and now works with the fix.
Updated release scripts to deal with JIRA accounts that have no last name
Update bin/jira.py
MODE-1763, MODE-1304 - Updated the ISPN dependency to 5.2.1 and Hibernate Search/Lucene to 4.2/3.6.

Because the new version of Infinispan does not allow by default duplicate MBeans with the same name, the tests had to be updated to specifically turn this option on for each used caches.
MODE-1769 Added tests that verify ISPN-2748 and MODE-1769 are resolved
MODE-1763 Removed the @Ignore from an integration test

Removed the @Ignore from the JDBCRepositoryIntegrationTest, which had
to be added to the changes for MODE-1826 since the fix for
MODE-1769 has not yet been corrected but will be when Infinispan
5.2.1.Final is used.
MODE-1763 - Updated Infinispan XML schema to 5.2 and logging to turn off useless INFO messages.
MODE-1764 - Updated the AS7 kit that will be provided as part of 3.2
- the former 7.1.1.kit has been removed (together will assemblies) because ISPN 5.2 is not compatible with AS7.1.1
- removed the modeshape-integration-tests folder as that was ported from 2.x and either the corresponding tests have been ported in various other places in 3.x or they no do apply anymore (connectors)
- changed our AS7 distribution kit to as72
- since integration with AS7.2.0 is still WIP, the integration modules have been commented out
MODE-1833 - JQOM Wildcard Query fails with Column 'null' does not exist on the table

Fixed with testcase.
Fix broken tests.
MODE-1832: ModeShape CMIS component has bug in JcrService

Corrects for use of  ">" and adds a basic test case.

https://issues.jboss.org/browse/MODE-1832
MODE-1587 - Updated the modeshape distribution so that it runs on a AS7.2 server and re-enabled the integration tests modules. However, for a local build to work, one needs for the time being a locally installed (via Maven) version of AS7.2.

 In the process of updating the kit, a couple of other things were updated:
 - exception processing around WritableSessionCache#persistChanges
 - logging of exceptions / errors in the ModeShape Webdav Servlet
Updated the JGroups test configuration, together with the IPv4 and IPv6 profiles. By default, neither IPv4 nor IPv6 will be forced, meaning that whatever the underlying OS supports will be used (see http://docs.oracle.com/javase/1.5.0/docs/guide/net/ipv6_guide/index.html for more information)

Also, It seems that on Windows (at least) JGroups 3.2 is a lot faster when using IPv6 than it is when using IPv4, so a new OS-dependent profile was added to modeshape-jcr. Also, it seems Arquillian doesn't work with IPv6, so IPv4 was enforced for the integration tests.
MODE-1587 - Moved the JBossAS modules from the standard build lifecycle into dedicated profiles, so that user can still run "mvn clean install". We should keep this at least until we know what the Maven availability of the AS7 dist zip will be.
MODE-1834 Corrected logic that creates workspaces when used with PESSIMISTIC locking

When Infinispan's PESSIMISTIC locking mode is enabled, ModeShape failed
to create workspaces. This is because PESSIMISTIC mode apparently
requires explicit transactions.

Two test cases were added to verify the functionality with different
Infinispan configurations (PESSIMISTIC and OPTIMISTIC). There were
already test cases for other configuration.
MODE-1758 No longer skipping the two TCK tests that had bugs

The two OUTER JOIN tests were fixed in Jackrabbit Tests 2.6.0, so
we are no longer skipping these tests.
MODE-1493 - Updated RestEASY to 2.3.5
MODE-1778 - Updated Tika to 1.3 and the AS7 modules schema to 1.2
MODE-1763 Changed from using deprecated methods (compatible with 5.1.x) to the newer 5.2.x style configuration builders.
MODE-1834 Corrected federation logic when pessimistic locking is enabled

When Infinispan's PESSIMISTIC locking mode is enabled, ModeShape failed
to properly create and remove federation projections.
This is because PESSIMISTIC mode apparently requires explicit transactions.

Recent changes to upgrade to Infinispan 5.2 and change over to the newer
configuration builder API causes some of these problems to be exposed.
These tests run fine again after the projection management logic was fixed.