Update thread pool settings in STOMP/WebSocket config

The clientInboundChannel and clientOutboundChannel now use twice
the number of available processors by default to accomodate for some
degree of blocking in task execution on average.

In practice these settings still need to be configured explicitly in
applications but these should serve as better default values than
the default values in ThreadPoolTaskExecutor.

Issue: SPR-11450
Harmonize log configuration

Prior to this commit, the codebase was using a mix of log4j.xml
and log4j.properties for test-related logging configuration. This
can be an issue as log4j takes the xml variant first when looking
for a default bootstrap configuration.

In practice, some modules declaring the properties variant were
taking the xml variant configuration from another module.

The general structure of the configuration has also been
harmonized to provide a standard console output as well as an
easy way to enable trace logs for the current module.
Fix handling of required payload.

A payload that is required will now throw an appropriate exception
regardless of if a conversion is required or not.

isEmptyPayload now takes the payload instead of the message
so that both the original payload and the converted payload, if
necessary, share the same logic.

JSR-303 validation is now consistently applied.

Issue: SPR-11577
Ensure default value of @Payload required is enforced

When no @Payload is provided, it is equivalent to @Payload with default
attribute values. Since the default value of required=true, then
an argument that's not annotated is required.
Add getter for the length of a WebSocket message
Add concurrent WebSocket session decorator (temp commit)

Issue: SPR-11586
Set custom handshakeHandler for XML sockjs config

Prior to this commit, configuring a custom handshakeHandler when setting
up a stomp-endpoint with SockJS would not be taken into account:

  <websocket:stomp-endpoint path="/foo">
    <websocket:handshake-handler ref="customHandler"/>
    <websocket:sockjs/>
  </websocket:stomp-endpoint>

This commit fixes this by creating and registering a
WebsocketTransportHandler (with this handshakeHandler) as a
transportHandler override for the SockJSService.

Issue: SPR-11568
Raise MessageConversionException in @Payload resolver

If a payload is present but conversion returns null (meaning no
converter knows how to convert), raise a MessageConversionException
that provides information about the type we were trying to convert
to and the message itself whose headers (namely content-type) contain
crucial information required to debug the problem.

Issue: SPR-11577
Javadoc: @ComponentScan is subject to @Conditional as well

Issue: SPR-11579
BufferedImageHttpMessageConverter ignores empty MIME types

Issue: SPR-11581
Polish ASM-based annotation processing

- AnnotationAttributesReadingVisitor no longer processes annotations
  from the java.lang.annotation package.

- Simplified logic in AnnotationReadingVisitorUtils
  getMergedAnnotationAttributes().

Issue: SPR-11574
Remove synchronized block around WebSocketSession.send

Since we now wrap the WebSocketSession with a concurrent decorator, the
synchronized keyword around message sending needed to be removed.

Issue: SPR-11586
Improve ConcurrentWebSocketSessionDecorator

Before this change the decorator ensured that for a specific WebSocket
session only one thread at a time can send a message. Other threads
attempting to send would have their messages buffered and each time
that occurs, a check is also made to see if the buffer limit has been
reached or the send time limit has been exceeded and if so the session
is closed.

This change adds further protection to ensure only one thread at a time
can perform the session limit checks and attempt to close the session.
Furthermore if the session has timed out and become unresponsive,
attempts to close it may block yet another thread. Taking this into
consideration this change also ensures that state associated with the
session is cleaned first before an attempt is made to close the session.

Issue: SPR-11450
Remove synchronized keywords from SockJsSession impls

Before this change SockJsSession implementations of WebSocketSession
used synchronization around its method implementations protecting
internal state and ensuring only a single thread is sending messages
at a time.

A WebSocketSession is generally expected to be used from one thread
at a time and now that application messages are sent through
ConcurrentWebSocketSessionDecorator, there is no concern about
application messages sent from the different threads.

While there are some remaining concerns, those can be addressed
without using the synchronized keyword. This change removes it from
the methods of all SockJS session implementations.

Issue: SPR-11450
Add CloseStatus to indicate unreliable session

When a send timeout is detected, the WebSocket session is now closed
with a custom close status that indicates so. This allows skipping
parts of the close logic that may cause further hanging.

Issue: SPR-11450
Polish
Adjust SockJS scheduler core pool size

Issue: SPR-11556
Disable SockJS heartbeat if STOMP heartbeat is on
Polish SockJS documentation
Document IE 8 and 9 related SockJS transport details

Issue: SPR-11496, SPR-11525