Fix minor issue in MockHttpServletRequest

Previously MockHttpServletRequest#sendRedirect did not set the HTTP status
or the Location header. This does not conform to the HttpServletRequest
interface.

MockHttpServletRequest will now:

  - Set the HTTP status to 302 on sendRedirect
  - Set the Location header on sendRedirect
  - Ensure the Location header and getRedirectedUrl are kept in synch

Issue: SPR-9594
Merge pull request #108 from rwinch/SPR-9594

* SPR-9594:
  Fix minor issue in MockHttpServletRequest
Fix typos in Spring MVC chapter of reference docs
Parameterize DeferredResult

Issue: SPR-9579
Create StandardServletAsyncWebRequest via reflection

Issue: SPR-9500
Fix DeferredResult typo in changelog
Ensure async Callables are in sync with the call stack

After this change each call stack level pushes and pops an async
Callable to ensure the AsyncExecutionChain is in sync with the
call stack. Before this change, a controller returning a "forward:"
prefixed string caused the AsyncExecutionChain to contain a
extra Callables that did not match the actual call stack.

Issue: SPR-9611
Fix issue with failing test from previous commit

Issue: SPR-9611
Add exclude patterns for mapped interceptors

Add the ability provide exclude patterns for mapped interceptors in the
MVC namespace and in the MVC Java config.

Issue: SPR-6570
Add options to configure content negotiation

The MVC Java config and the MVC namespace now support options to
configure content negotiation. By default both support checking path
extensions first and the "Accept" header second. For path extensions
.json, .xml, .atom, and .rss are recognized out of the box if the
Jackson, JAXB2, or Rome libraries are available. The ServletContext
and the Java Activation Framework may be used as fallback options
for path extension lookups.

Issue: SPR-8420
Add ContentNegotiationManagerFactoryBean

The new FactoryBean facilitates the creation of a
ContentNegotiationManager in XML configuration.

Issue: SPR-8420
Fix typo in MockFilterChain
Improve tests for detection of @MVC annotations

Issue: SPR-9601
Use a default for INTROSPECT_TYPE_LEVEL_MAPPING

Usually this request attribute is set for all sub-classes of
AbstractUrlHandlerMapping and therefore whenever
AnnotationMethodHandlerAdapter is used. However, having a
default value to fall back on in AnnotationMethodHandlerAdapter
is still appropriate in general and also considering the Javadoc
of HandlerMapping.INTROSPECT_TYPE_LEVEL_MAPPING.

Issue: SPR-9629
Support named dispatchers in MockServletContext

Currently the getNamedDispatcher(String) method of MockServletContext
always returns null. This poses a problem in certain testing scenarios
since one would always expect at least a default Servlet to be present.
This is specifically important for web application tests that involve
the DefaultServletHttpRequestHandler which attempts to forward to the
default Servlet after retrieving it by name. Furthermore, there is no
way to register a named RequestDispatcher with the MockServletContext.

This commit addresses these issues by introducing the following in
MockServletContext.

 - a new defaultServletName property for configuring the name of the
   default Servlet, which defaults to "default"
 - named RequestDispatchers can be registered and unregistered
 - a MockRequestDispatcher is registered for the "default" Servlet
   automatically in the constructor
 - when the defaultServletName property is set to a new value the
   the current default RequestDispatcher is unregistered and replaced
   with a MockRequestDispatcher for the new defaultServletName

Issue: SPR-9587
Fix typo in TransactionManagementConfigurer Javadoc
Support single, unqualified tx manager in the TCF

TransactionalTestExecutionListener currently requires that the
PlatformTransactionManager bean be named "transactionManager" by
default. Otherwise, the bean name can only be overridden via the
transactionManager attribute of @TransactionConfiguration or the value
attribute of @Transactional.

However, if there is only a single PlatformTransactionManager in the
test's ApplicationContext, then the requirement to specify the exact
name of that bean (or to name it exactly "transactionManager") is often
superfluous.

This commit addresses this issue by refactoring the
TransactionalTestExecutionListener so that it is comparable to the
algorithm for determining the transaction manager used in
TransactionAspectSupport for "production" code. Specifically, the TTEL
now uses the following algorithm to retrieve the transaction manager.

 - look up by type and qualifier from @Transactional
 - else, look up by type and explicit name from
   @TransactionConfiguration
 - else, look up single bean by type
 - else, look up by type and default name from @TransactionConfiguration

Issue: SPR-9645
Support TransactionManagementConfigurer in the TCF

Currently the Spring TestContext Framework looks up a
PlatformTransactionManager bean named "transactionManager". The exact
name of the bean can be overridden via @TransactionConfiguration or
@Transactional; however, the bean will always be looked up 'by name'.

The TransactionManagementConfigurer interface that was introduced in
Spring 3.1 provides a programmatic approach to specifying the
PlatformTransactionManager bean to be used for annotation-driven
transaction management, and that bean is not required to be named
"transactionManager". However, as of Spring 3.1.2, using the
TransactionManagementConfigurer on a @Configuration class has no effect
on how the TestContext framework looks up the transaction manager.
Consequently, if an explicit name or qualifier has not been specified,
the bean must be named "transactionManager" in order for a transactional
integration test to work.

This commit addresses this issue by refactoring the
TransactionalTestExecutionListener so that it looks up and delegates to
a single TransactionManagementConfigurer as part of the algorithm for
determining the transaction manager.

Issue: SPR-9604
Polish Javadoc for NoSuchBeanDefinitionException
Polish error message in BeanFactoryAnnotationUtils