Reflect @Async executor qual. 3.2=>3.1.2 backport

@Async executor qualification has been backported to 3.1.2. This commit
updates all @since tags appropriately, as well as carrying over the
changes backported to the spring-task-3.1 schema.

Issue: SPR-6847, SPR-9443
Reflect 3.2=>3.1.2 backports in @since tags etc

Issue: SPR-9443, SPR-6847, SPR-9446, SPR-9444, SPR-9439, SPR-9302,
       SPR-9507, SPR-9238, SPR-9397, SPR-9406, SPR-9502
Improve SimpleStreamingClientHttpRequest performance

Ensure that NonClosingOutputStream calls with a byte array call the
corresponding methods of the underlying OutputStream rather than
relying on the default NonClosingOutputStream implementation, which
writes one bte at a time. This significantly improves performance.

Issues: SPR-9530
Merge pull request #101 from philwebb/SPR-9530

* SPR-9530:
  Improve SimpleStreamingClientHttpRequest performance
Reduce logging in HandlerExecutionChain

Before this change the HandlerExecitionChain logged errors each time a
an AsyncHandlerInterceptor returned a null async Callable, a condition
which is acceptable.

SPR-9524
refined fix so that XStreamMarshaller does not wrap IllegalArgumentException

Issue: SPR-9536
Use BufferedInputStream in SimpleMetaDataReader to double performance

Issue: SPR-9528
added "repeatCount" bean property to Quartz SimpleTriggerFactoryBean

Issue: SPR-9521
moved getInputStream() not-null requirement to InputStreamSource itself; removed misleading "throws IllegalStateException" declaration

Issue: SPR-9561
DispatcherPortlet does not forward event exceptions to the render phase by default

Issue: SPR-9287
polishing
preparations for 3.2 M2
Add defaultCharset field to StringHttpMessageConverter

Before this change the StringHttpMessageConverter used a fixed charset
"ISO-8859-1" if the requested content type did not specify one. This
change adds a defaultCharset field and a constructor to configure it in
StringHttpMessageConverter.

Issue: SPR-9487
Fix minor issue in HandlerMethod

Before this change HandlerMethod used ClassUtils.getUserClass(Class<?>)
to get the real user class, and not one generated by CGlib. However it
failed to that under all circumstances. This change fixes that.

Issue: SPR-9490
Resolve nested placeholders via PropertyResolver

Prior to this change, PropertySourcesPropertyResolver (and therefore
all AbstractEnvironment) implementations failed to resolve nested
placeholders as in the following example:

    p1=v1
    p2=v2
    p3=${v1}:{$v2}

Calls to PropertySource#getProperty for keys 'p1' and 'v1' would
successfully return their respective values, but for 'p3' the return
value would be the unresolved placeholders. This behavior is
inconsistent with that of PropertyPlaceholderConfigurer.

PropertySourcesPropertyResolver #getProperty variants now resolve any
nested placeholders recursively, throwing IllegalArgumentException for
any unresolvable placeholders (as is the default behavior for
PropertyPlaceholderConfigurer). See SPR-9569 for an enhancement that
will intoduce an 'ignoreUnresolvablePlaceholders' switch to make this
behavior configurable.

This commit also improves error output in
PropertyPlaceholderHelper#parseStringValue by including the original
string in which an unresolvable placeholder was found.

Issue: SPR-9473, SPR-9569
reintroduced static DEFAULT_CHARSET field

 Issue: SPR-9487
added "jtaTransactionManager" property to Hibernate 4 LocalSessionFactoryBean/Builder

Issue: SPR-9480
preparations for 3.2 M2
Add support for global @ExceptionHandler methods

Before this change @ExceptionHandler methods could be located in and
apply locally within a controller. The change makes it possible to have
such methods applicable globally regardless of the controller that
raised the exception.

The easiest way to do that is to add them to a class annotated with
`@ExceptionResolver`, a new annotation that is also an `@Component`
annotation (and therefore works with component scanning). It is also
possible to register classes containing `@ExceptionHandler` methods
directly with the ExceptionHandlerExceptionResolver.

When multiple `@ExceptionResolver` classes are detected, or registered
directly, the order in which they're used depends on the the `@Order`
annotation (if present) or on the value of the order field (if the
Ordered interface is implemented).

Issue: SPR-9112
Fix issue with incorrect class import

Issue: SPR-9112