Improve documentation of annotated class support in the TCF

Updated all Javadoc in the Spring TestContext Framework (TCF) to explain
and refer to 'annotated classes' instead of 'configuration classes'.

Specifically, @ContextConfiguration now explicitly defines what is meant
by 'annotated classes', and various other classes now refer to this
definition. Otherwise, the term 'configuration class' has simply been
replaced with 'annotated class'.

Also deleted cross references to deprecated JUnit 3.8 classes and
formatted Javadoc in general for greater readability.

Issue: SPR-9401
Decode path vars when url decoding is turned off

When URL decoding is turned off in AbstractHandlerMapping, the
extracted path variables are also not encoded. Turning off URL decoding
may be necessary for request mapping to work correctly when the path
may contain the (encoded) special character '/'. At the same time there
is no good reason not to leave path variables encoded. This change
ensures path variables are encoded when URL decoding is turned off.

Issue: SPR-9098
Decode path vars in pre-3.1 `@MVC` support clases too

See the commit comments for:
https://github.com/SpringSource/spring-framework/commit/57307a0b2e5bce8f70d5deddf8df11d034dc8c5a

This commit also applies the change to pre-3.1 `@MVC` suppor classes.

Issue: SPR-6951
Add required flag to @RequestBody

If true and there is no body => HttpMessageNotReadableException
If false and there is no body, the argument resolves to null.

Issue: SPR-9239
Delete superfluous fail() invocations in RequestResponseBodyMethodProcessorTests

Several test methods in RequestResponseBodyMethodProcessorTests
are currently annotated with @Test(expected=…) and additionally contain:

    fail("Expected exception");

This combination is superfluous, and the unnecessary fail() invocations
have therefore been removed.
Update documentation of 'annotated class' support in the TCF

Updated the testing chapter of the reference manual to refer to 
'annotated classes' instead of 'configuration classes' where 
appropriate.

Also revised the content and examples in the @ContextConfiguration 
annotation section, mentioned Gradle, and reformatted the entire text.

Issue: SPR-9401
Update spring.schemas to reflect 3.2 schemas

Commit 180c5b2ef6c16f66145a4250b597a093e566d922 introduced 3.2 versions
of all spring-* schemas; this commit updates spring.schemas mapping
files to include these new versions.
Add value-type attrib to beans->map->entry element

Previously, the <value> subelement of a map <entry> allowed one to
specify the type of a specific map entry value. This patch allows a
value-type attribute as well, such that instead of the following
syntax

    <entry key="x-message-ttl">
        <value type="java.lang.Long">100</value>
    </entry>
    <entry key="x-ha-policy" value="all" />

one can now use the more concise form

    <entry key="x-message-ttl" value="100" value-type="java.lang.Long"/>
    <entry key="x-ha-policy" value="all"/>

The new value-type attribute may be used at the <map> level as well,
indicating that all elements are of the same type.

Appropriate tests have been added exercising value-type at the <map> and
<entry> levels.

Issue: SPR-9249
Merge branch garyrussell/SPR-9249

* SPR-9249:
  Add value-type attrib to beans->map->entry element
Polish doc for 'annotated class' support in TCF

Revised the content in the @ContextConfiguration annotation section.

Issue: SPR-9401
Verify scope support for 'lite' @Beans in the TCF

Introduced AtBeanLiteModeScopeTests integration tests to verify proper 
scoping of beans created in 'lite' mode.

Updated comments in TACCWithoutACTests to better reflect the runtime 
behavior for 'lite' @Bean methods.

Issue: SPR-9401
Update @Bean Javadoc re: 'lite' mode, scope, etc.

Updated the "@Bean Lite Mode" section in order to properly document 
scoping and lifecycle semantics.

Also fleshed out the discussion of the non-applicability of 'inter-bean 
references' in lite mode.

Issue: SPR-9425
Fix issue with resolution of WebDataBinder argument

There is usually not need to put annotations on a WebDataBinder
argument in an `@InitBinder` method. However, the presence of any
annotation prevented the successful resolution of the argument.
This fix addresses the issue.

Issue: SPR-8946
Doc. usage of JSR-250 lifecycle annotations in TCF

The reference manual previously did not mention the applicability of
JSR-250 lifecycle annotations within the TestContext framework. The
lacking documentation here has lead to misunderstandings of the support
provided for @PostConstruct and @PreDestroy in test classes.

The testing chapter of the reference manual has therefore been updated
to explicitly define the limited support for these annotations.

Also introduced Jsr250LifecycleTests for empirical verification of the 
expected behavior.

Issue: SPR-4868
Refactor and deprecate TransactionAspectUtils

TransactionAspectUtils contains a number of methods useful in
retrieving a bean by type+qualifier. These methods are functionally
general-purpose save for the hard coding of PlatformTransactionManager
class literals throughout.

This commit generifies these methods and moves them into
BeanFactoryUtils primarily in anticipation of their use by async method
execution interceptors and aspects when performing lookups for qualified
executor beans e.g. via @Async("qualifier").

The public API of TransactionAspectUtils remains backward compatible;
all methods within have been deprecated, and all calls to those methods
throughout the framework refactored to use the new BeanFactoryUtils
variants instead.
Polish async method execution infrastructure

In anticipation of substantive changes required to implement @Async
executor qualification, the following updates have been made to the
components and infrastructure supporting @Async functionality:

 - Fix trailing whitespace and indentation errors
 - Fix generics warnings
 - Add Javadoc where missing, update to use {@code} tags, etc.
 - Avoid NPE in AopUtils#canApply
 - Organize imports to follow conventions
 - Remove System.out.println statements from tests
 - Correct various punctuation and grammar problems
Support executor qualification with @Async#value

Prior to this change, Spring's @Async annotation support was tied to a
single AsyncTaskExecutor bean, meaning that all methods marked with
@Async were forced to use the same executor. This is an undesirable
limitation, given that certain methods may have different priorities,
etc. This leads to the need to (optionally) qualify which executor
should handle each method.

This is similar to the way that Spring's @Transactional annotation was
originally tied to a single PlatformTransactionManager, but in Spring
3.0 was enhanced to allow for a qualifier via the #value attribute, e.g.

  @Transactional("ptm1")
  public void m() { ... }

where "ptm1" is either the name of a PlatformTransactionManager bean or
a qualifier value associated with a PlatformTransactionManager bean,
e.g. via the <qualifier> element in XML or the @Qualifier annotation.

This commit introduces the same approach to @Async and its relationship
to underlying executor beans. As always, the following syntax remains
supported

  @Async
  public void m() { ... }

indicating that calls to #m will be delegated to the "default" executor,
i.e. the executor provided to

  <task:annotation-driven executor="..."/>

or the executor specified when authoring a @Configuration class that
implements AsyncConfigurer and its #getAsyncExecutor method.

However, it now also possible to qualify which executor should be used
on a method-by-method basis, e.g.

  @Async("e1")
  public void m() { ... }

indicating that calls to #m will be delegated to the executor bean
named or otherwise qualified as "e1". Unlike the default executor
which is specified up front at configuration time as described above,
the "e1" executor bean is looked up within the container on the first
execution of #m and then cached in association with that method for the
lifetime of the container.

Class-level use of Async#value behaves as expected, indicating that all
methods within the annotated class should be executed with the named
executor. In the case of both method- and class-level annotations, any
method-level #value overrides any class level #value.

This commit introduces the following major changes:

 - Add @Async#value attribute for executor qualification

 - Introduce AsyncExecutionAspectSupport as a common base class for
   both MethodInterceptor- and AspectJ-based async aspects. This base
   class provides common structure for specifying the default executor
   (#setExecutor) as well as logic for determining (and caching) which
   executor should execute a given method (#determineAsyncExecutor) and
   an abstract method to allow subclasses to provide specific strategies
   for executor qualification (#getExecutorQualifier).

 - Introduce AnnotationAsyncExecutionInterceptor as a specialization of
   the existing AsyncExecutionInterceptor to allow for introspection of
   the @Async annotation and its #value attribute for a given method.
   Note that this new subclass was necessary for packaging reasons -
   the original AsyncExecutionInterceptor lives in
   org.springframework.aop and therefore does not have visibility to
   the @Async annotation in org.springframework.scheduling.annotation.
   This new subclass replaces usage of AsyncExecutionInterceptor
   throughout the framework, though the latter remains usable and
   undeprecated for compatibility with any existing third-party
   extensions.

 - Add documentation to spring-task-3.2.xsd and reference manual
   explaining @Async executor qualification

 - Add tests covering all new functionality

Note that the public API of all affected components remains backward-
compatible.

Issue: SPR-6847
Merge branch cbeams/SPR-6847

* SPR-6847:
  Support executor qualification with @Async#value
  Polish async method execution infrastructure
  Refactor and deprecate TransactionAspectUtils
Test meta-@Async executor qualification

Prove that Async#value is respected even when using @Async as a meta
annotation.

Issue: SPR-6847
Add convenient WebAppInitializer base classes

This commit introduces three abstract WebApplicationInitializers, to be
used in the typical setup of a Spring-based web application.

 - AbstractContextLoaderInitializer provides an abstract base class for
   registering a ContextLoaderListener.

 - AbstractDispatcherServletInitializer provides an abstract base class
   for registering a DispatcherServlet, with an optional root context.

 - AbstractAnnotationConfigDispatcherServletInitializer provides an
   abstract base class for registering a DispatcherServlet and optional
   ContextLoaderListener based on annotated (e.g. @Configuration)
   classes.

Issue: SPR-9300