Add URI and method name on ResourceAccess

Issue: SPR-9325
Merge pull request #82 from rcrathore/master

* pull82-rcrathore-master:
  Add URI and method name on ResourceAccess
Add PATCH to "Allow" header for OPTIONS requests
Calling cancel on a Future returned by a TaskScheduler works reliably now

Issue: SPR-9821
Fixed potential race condition in concurrent calling of autowired methods on a prototype bean

Autowired methods might have been skipped on subsequent creation of further bean instances due to the 'skip' flag set to false outside of the synchronized block, with another thread entering the block and setting the flag to true in the meantime.

Issue: SPR-9806
Calling cancel on a Future returned by a TaskScheduler works reliably now

Issue: SPR-9821
Add ObjectToStringHttpMessageConverter

This new converter uses StringHttpMessageConverter internally combined
with a ConversionService for converting String content to and from the
target object type.

Issue: SPR-9738
Support opaque URIs in UriComponentsBuilder

Before this commit, UriComponentsBuilder did not handle opaque URIs at
all. After this commit it does.

Support is introduced by making UriComponents an abstract base class,
and having two concrete subclasses: HierarchicalUriComponents and
OpaqueUriComponents. The former is more or less the same as the old
UriComponents class.

Issue: SPR-9798
Merge pull request #148 from poutsma/SPR-9798

* poutsma-SPR-9798:
  Support opaque URIs in UriComponentsBuilder
Polish ObjectToStringHttpMessageConverter

Issue: SPR-9738
Work around Servlet dependency in content negotiation

Before this change the PathExtensionContentNegotiationStrategy accessed
the ServletContext via request.getServletContext, which is Servlet 3
specific. To work around it, there is now a Servlet-specific sub-class
that accepts a ServletContext as a constructor argument.

The ContentNegotiationManagerFactoryBean is now ServletContextAware and
if it has a ServletContext it creates the Servlet-specific sub-class
of PathExtensionContentNegotiationStrategy.

The ContentNegotiationManagerFactoryBean is now also used in several
places internally -- MVC namespace, MVC Java config, and the
ContentNegotiatingViewResolver -- to reduce duplication.

Issue: SPR-9826
LiveBeansView produces a well-defined (and valid) JSON document now

Issue: SPR-9662
ResourceBundleMessageSource supports "defaultEncoding", "fallbackToSystemLocale", "cacheSeconds"

These features require Java 6 or higher due to their dependency on the ResourceBundle.Control class. To some degree, ResourceBundleMessageSource catches up with ReloadableResourceBundleMessageSource now. However, as noted in the javadoc, there are still severe limitations in the standard ResourceBundle class that justify an ongoing investment in our own ReloadableResourceBundleMessageSource (based on the Spring resource abstraction, with manual parsing of properties files).

Issue: SPR-7392
TransactionInterceptor avoids reflective method search for method identification

As of Spring 3.0.4, we were trying to expose the target method signature as transaction name. Unfortunately, the algorithm called the ClassUtils.getMostSpecificMethod helper method which performs a quite expensive reflective search. As of this commit, we're simply concatenating the target class name with the method name, accepting the use of the concrete target class (which is arguably more meaningful for monitoring anyway) even when the method implementation actually sits on a base class.

Issue: SPR-9802
ClassUtils.getMostSpecificMethod uses Class.getMethod code path in case of a public method

This should be significantly faster than our standard algorithm, for a very common case. Motivated by SPR-9802, even if the fix there uses a different approach, with transaction name determination not calling getMostSpecificMethod at all anymore.

Issue: SPR-9802
Polish MockFilterChain

A reset method now allows it to be invoked more than once each time
storing the request and response with which it was invoked.
Add mock implementations of Http[Input|Output]Message
Sync up MockHttpServletResponse copies in test sources
Polish LiveBeansView Javadoc and suppress warnings
Add Spring MVC Test framework

This commit adds the spring-test-mvc project [1] to the Spring
Framework as part of the spring-test module.

The sources are added as a root-level project called "spring-test-mvc"
instead of under "spring-test" because the new sources need to be
compiled with Servlet 3 while the current "spring-test" sources require
Servlet 2.5 and the Eclipse IDE does not support having different
classpaths for the same project.

The Gradle build produces a single spring-test jar that contains
sources from both "spring-test" and "spring-test-mvc". This merge is
made possible through merge-dist.gradle as follows:

- jar tasks of the "from" project execute tasks of the "to" project
- "to" project is added to the classpath of the "from" project
- "to" project pom is updated with entries from the "from" project

For further details see documentation in merge-dist.gradle.

Special thanks to everyone who contributed to the initial development
of the Spring MVC Test framework:

 Arjen Poutsma <poutsma@mac.com>
 Craig Walls <cwalls@vmware.com>
 Frans Flippo <fransflippo@utopia.orange11.nl>
 Harry Lascelles <harry@firstbanco.com>
 Irfan <mail.urfi@gmail.com>
 Jörg Rathlev <joerg.rathlev@s24.com>
 Keesun Baik <whiteship2000@gmail.com>
 Keesun Baik <whiteship@epril.com>
 Matthew Reid <matthew.reid@nakedwines.com>
 Nils-Helge Garli Hegvik <Nils-Helge.Hegvik@telenor.com>
 Rob Winch <rwinch@vmware.com>
 Scott Frederick <sfrederick@vmware.com>
 Sven Filatov <sven.filatov@gmail.com>
 Thomas Bruyelle <thomas.bruyelle@gmail.com>
 youngm <youngm@gmail.com>

[1]: https://github.com/SpringSource/spring-test-mvc

Issue: SPR-9859, SPR-7951