Polish WebSocketSession

Update methods available on WebSocketSession interface.
Introduce DelegatingWebSocketSession interface.
Fix configuration issues in DefaultSockJsService
Add HandshakeInterceptor

A HandshakeInterceptor can be used to intercept WebSocket handshakes
(or SockJS requests where a new session is created) in order to
inspect the request and response before and after the handshake
including the ability to pass attributes to the WebSocketHandler,
which the hander can access through
WebSocketSession.getHandshakeAttributes()

An HttpSessionHandshakeInterceptor is available that can copy
attributes from the HTTP session to make them available to the
WebSocket session.

Issue: SPR-10624
Support 'empty' StreamSource in Jaxb2Marshaller

Added support for StreamSources that do not have a InputStream or
Reader, but do have a System ID.

Issue: 10828
Add canRead/Write to MarshallingHttpMessageConverter

Issue: SPR-10463
Remove Cookie support from ServerHttpRequest

Although ServletHttpRequest provides access to Cookies, other
implementations may not. At the moment this was only needed
for SockJS to check the value of the JSESSIONID cookie. This
is now down by parsing the raw cookie values locally.

If comprehensive cookie support is to be added, we should
probably consider HttpHeaders as a potential candidate.
Remove qetQueryParams from ServerHttpRequest
Integration tests for the broker relay
Publish events about broker's availability

Components that are using a StompBrokerRelayMessageHandler may want
to know whether or not the broker's unavailable. If they're sending
messages to the relay via an asynchronous channel there's currently
no way for them to find this out.

This commit enhances StompBrokerRelayMessageHandler to publish
application events when the broker's availability changes:
BrokerBecameAvailableEvent and BrokerBecameUnavailableEvent.
Irrespective of the number of relay sessions only a single event is
published for each change in the broker's availability.
Add reconnect logic to the relay's system session

Upgrade to Reactor snapshot builds to take advantage of TcpClient's
reconnect support that was added post-M1. Now, the system relay session
will try every 5 seconds to establish a connection with the broker, both
when first connecting and in the event of subsequently becoming
disconnected.

A more sophisticated reconnection policy, including back off and
failover to different brokers, is possible with the Reactor API. We may
want to enhance the relay's reconnection policy in the future.

Typically, a broken connection is identified by the failure to forward
a message to the broker. As things stand, the message id then discarded.
Any further messages that are forwarded before the connection's been
re-established are queued for forwarding once the CONNECTED frame's been
received. We may want to consider also queueing the message that failed
to send, however we would then need to consider the possibility of the
message itself being what caused the broker to close the connection
and resending it would simply cause the connection to be closed again.
Improve broker availability events

Use a single class for the broker availability event with a boolean
that indicates whether or not the broker is available, rather than one
event for an available broker and one event for an unavailable broker.

Publish broker availability events in SimpleBrokerMessageHandler so that
it can be used as a drop-in replacement for
StompBrokerRelayMessageHandler.
Add ActiveMQ-based STOMP relay integration tests
Polish StompBrokerRelayMessageHandler
Explicit support for JPA 2.0's QueryTimeoutException, LockTimeoutException and PessimisticLockException

Issue: SPR-10815
Explicit support for Hibernate 3.6's QueryTimeoutException, PessimisticLockException and OptimisticLockException

Issue: SPR-10815
Explicit support for Hibernate 4.0's QueryTimeoutException, PessimisticLockException, PessimisticEntityLockException and OptimisticEntityLockException

Issue: SPR-10815
Introduced local support for Hibernate 3.6 and 4.x exception translation to HibernateJpaDialect

Since Hibernate 3.6 and 4.x differ in exception handling now, this change makes HibernateJpaDialect independent from orm.hibernate3 now and avoids introducing a conditional dependency on orm.hibernate4.

Issue: SPR-10815
Javadoc cleanup for Hibernate 3.6+
GenericTypeResolver properly handles bound parameterized type

Issue: SPR-10819
Revised JSR-303 references to include JSR-349 (Bean Validation 1.1) as well

Issue: SPR-10813