Fixed setDeliveryPersistent javadoc

Issue: SPR-3983
SourceHttpMessageConverter's supports implementation needs to check for StAXSource

Issue: SPR-11341
Polish
Add DestinationUserNameProvider interface

The interface is to be implemented in addition to
java.security.Principal when Principal.getName() is not globally unique
enough for use in user destinations.

Issue: SPR-11327
Use DestinationUserNameProvider with @SendTo

Issue: SPR-11327
Fix SerializableTypeWrapper equals() performance

Change SerializableTypeWrapper proxies to directly call equals() methods
on the underlying Type, rather than possibly generating more wrappers.

This should help to improve performance, especially as the equals()
method is called many times when the ResolvableType cache is checked.

Issue: SPR-11335
Encode user names in user destanations

Issue: SPR-11302
Introduce EJB-based transactional tests in the TCF

This commit introduces transactional integration tests executing
against both JUnit and TestNG in the TestContext framework (TCF) using
@TransactionAttribute in EJBs instead of Spring’s @Transactional
annotation.

These tests disprove the claims raised in SPR-6132 by demonstrating that
transaction support in the TCF works as expected when a transactional
EJB method that is configured with TransactionAttribute.REQUIRES_NEW is
invoked. Specifically:

 - The transaction managed by the TCF is suspended while such an EJB
   method is invoked.
 - Any work performed within the new transaction for the EJB method is
   committed after the method invocation completes.
 - The transaction managed by the TCF is resumed and subsequently
   either rolled back or committed as necessary based on the
   configuration of @Rollback and @TransactionConfiguration.

The configuration for the JUnit-based tests is straightforward and self
explanatory; however, the configuration for the TestNG tests is less
intuitive.

In order to ensure that the TCF functions properly, the developer must
make certain that test methods within a given TestNG test class are
executed in the proper order. In a stand-alone test class this is
straightforward; however, in a test class hierarchy with dependent
methods, it is necessary to configure TestNG so that all methods within
an individual test class are executed in isolation from other test
methods in different test classes. This can be achieved by configuring
a test class to run in its own uniquely identified suite (e.g., by
annotating each concrete TestNG-based test class with @Test(suiteName =
"< Some Unique Suite Name >")).

Issue: SPR-6132