JdbcUtils uses JDBC 4.1 getObject(int, Class) for unknown ResultSet value types

Comes with general JDBC 3.0+ baseline upgrade, removing defensive measures.

Issue: SPR-11600
JDBC 3.0 related javadoc overhaul

Issue: SPR-11600
Polish Javadoc for SpringJUnit4ClassRunner
Consistent documentation for both 'close' and 'shutdown' as inferred destroy methods

Issue: SPR-11680
SimpleApplicationEventMulticaster supports a configurable ErrorHandler strategy

Issue: SPR-11551
Polish Javadoc in SimpleApplicationEventMulticaster
Support EOF as statement separator in SQL scripts

Prior to Spring Framework 4.0.3, it was possible to supply a bogus
statement separator (i.e., a separator string that does not exist in
the configured SQL scripts) to ResourceDatabasePopulator with the side
effect that the entire contents of a script file would be interpreted
as a single SQL statement.

This undocumented feature was never intentional; however, some
developers came to rely on it. Unfortunately, changes made in
conjunction with SPR-9531 and SPR-11560 caused such scenarios to no
longer work.

This commit introduces first-class support for executing scripts which
contain a single statement that spans multiple lines but is not
followed by an explicit statement separator.

Specifically, ScriptUtils.EOF_STATEMENT_SEPARATOR may now be specified
as a 'virtual' statement separator to denote that a script contains a
single statement and no actual separator.

Issue: SPR-11687
Make EOF_STATEMENT_SEPARATOR XML friendly

Changed the value of ScriptUtils.EOF_STATEMENT_SEPARATOR from
"<<< END OF SCRIPT >>>" to "^^^ END OF SCRIPT ^^^" so that the angle
brackets do not have to be escaped in XML configuration files.

Issue: SPR-11687
Polish AbstractDatabasePopulatorTests
Improve Javadoc in SQL script support classes
Assert preconditions in ResourceDatabasePopulator

Prior to this commit ResourceDatabasePopulator did not assert any
preconditions for constructor and method arguments. Consequently,
errors would not be encountered until the populator was executed.

This commit addresses this issue by ensuring that preconditions for
constructor and method arguments are asserted immediately, throwing
IllegalArgumentExceptions where appropriate.

Issue: SPR-11690
Add script after setting scripts in RsrcDbPopultr

Prior to this commit it was impossible to add additional scripts to a
ResourceDatabasePopulator after setScripts() had been invoked.

This commit fixes this by ensuring that the internal scripts list
continues to be modifiable when setScripts() is invoked.

Issue: SPR-11691
Enhance MessageHeaderAccessor support

Refine semantics of ID and TIMESTAMP headers provided to protected
MessageHeaders constructor.

Refactor internal implementation of MessageHeaderAccessor.

Support mutating headers from a single thread while a message is being
built (e.g. StompDecoder creating message + then adding session id).

Improve immutablity in NativeMessageHeaderAccessor and in
StompHeaderAccessor.

Optimize object creation for initializing messages and subsequent
accessing their headers.

Introduce MessageHeaderAccessorFactory support to enable applying a
common strategies for ID and TIMESTAMP generation to every message.

Add MessageBuilder shortcut factory method for creating messages from
payload and a full-prepared MessageHeaders instance. Also add
equivalent constructors to GenericMessage and ErrorMessage.

Issue: SPR-11468
Make use of enhanced MessageHeaderAccessor support

Mutate rather than re-create headers when decoding STOMP messages
before a message is sent on a message channel.

Use MessageBuilder.createMessage to ensure the fully prepared
MessageHeaders is used directly MessageHeaderAccessor instance.

Issue: SPR-11468
Support mutable headers in MessagingTemplate

AbstractMessageConverter and messaging template implementations now
detect and use mutable headers if passed in.

The SimpMessagingTemplate is optimized to supporting using a single
MessageHeaders instance while preparing a message.

This commit also updates code using the SimpMessagingTemplate to take
advantage of its new capabilities.

Issue: SPR-11468
Merge pull request #512 from rstoyanchev/message-headers

Enhance MessageHeaderAccessor support and optimize message creation
Switch BufferingStompDecoder to decoration

The BufferingStompDecoder now decorates rather than extend
StompDecoder. This allows a single StompDecoder instance to be
configured and extended independantly while buffering remains a
separate concern.
Polish ResourceDatabasePopulatorTests
JMS annotation-driven endpoints.

This commit adds the support of JMS annotated endpoint. Can be
activated both by @EnableJms or <jms:annotation-driven/> and
detects methods of managed beans annotated with @JmsListener,
either directly or through a meta-annotation.

Containers are created and managed under the cover by a registry
at application startup time. Container creation is delegated to a
JmsListenerContainerFactory that is identified by the containerFactory
attribute of the JmsListener annotation. Containers can be
retrieved from the registry using a custom id that can be specified
directly on the annotation.

A "factory-id" attribute is available on the container element of
the XML namespace. When it is present, the configuration defined at
the namespace level is used to build a JmsListenerContainerFactory
that is exposed with the value of the "factory-id" attribute. This can
be used as a smooth migration path for users having listener containers
defined at the namespace level.

The configuration can be fine-tuned by implementing the
JmsListenerConfigurer interface which gives access to the registrar
used to register endpoints. This includes a programmatic registration
of endpoints in complement to the declarative approach. A default
JmsListenerContainerFactory can also be specified to be used if no
containerFactory has been set on the annotation.

Annotated methods can have flexible method arguments that are similar
to what @MessageMapping provides. In particular, jms listener endpoint
methods can fully use the messaging abstraction, including convenient
headers accessors. It is also possible to inject the raw
javax.jms.Message and the Session for more advanced use cases. By
default, the payload can be injected as long as the conversion
service is able to convert it from the original type of the JMS
payload. The return type can also be an instance of Spring's
Message abstraction. Instead of just converting the payload, such
response type allow to communicate standard and custom headers.

The JmsHeaderMapper infrastructure from Spring integration has also
been migrated to the Spring framework. SimpleJmsHeaderMapper is based
on SI's DefaultJmsHeaderMapper. The simple implementation maps all
JMS headers so that the generated Message abstraction has all the
information stored in the protocol specific message.

Issue: SPR-9882