Previously MockHttpServletRequestBuilder merge method would append the
parent's (default) RequestPostProcessor implementations to the end. This
means that the default RequestPostProcessor implementations would override
values set by previous RequestPostProcessor implementations.

This commit ensures that the default RequestPostProcessor are preformed
first so that additional RequestPostProcessor implementations override
the defaults.

Issue: SPR-12945

Issue: SPR-12928

Issue: SPR-12296

Issue: SPR-12296

Issue: SPR-12599

Issue: SPR-12599

This commit introduces support for finding annotations on abstract,
bridge, and interface methods in AnnotatedElementUtils.

 - Introduced dedicated findAnnotationAttributes() methods in
   AnnotatedElementUtils that provide first-class support for
   processing methods, class hierarchies, interfaces, bridge methods,
   etc.

 - Introduced find/get search algorithm dichotomy in
   AnnotatedElementUtils which is visible in the public API as well as
   in the internal implementation. This was necessary in order to
   maintain backwards compatibility with the existing API (even though
   it was undocumented).

 - Reverted all recent changes made to the "get semantics" search
   algorithm in AnnotatedElementUtils in order to ensure backwards
   compatibility, and reverted recent changes to
   JtaTransactionAnnotationParser and SpringTransactionAnnotationParser
   accordingly.

 - Documented internal AnnotatedElementUtils.Processor<T> interface.

 - Enabled failing tests and introduced
   findAnnotationAttributesFromBridgeMethod() test in
   AnnotatedElementUtilsTests.

 - Refactored ApplicationListenerMethodAdapter.getCondition() and
   enabled failing test in TransactionalEventListenerTests.

 - AnnotationUtils.isInterfaceWithAnnotatedMethods() is now package
   private.

Issue: SPR-12738, SPR-11514, SPR-11598

Before 4.2 the MvcUriComponentsBuilder exposed only static factory
methods and therefore there should be no reason for it to extend
UriComponentsBuilder (design oversight). It's also highly unlikely
for application code to treat MvcUriCB as UriCB since there is no
need and no way to obtain an instance (constructor is protected).

This change removes the base class declaration from MvcUriCB.

Issue: SPR-12617

Before this change MvcUriComponentsBuilder exposed only static factory
methods for creating links where the links are relative to the current
request or a baseUrl explicitly provided as an argument.

This change allows creating an MvcUriComponents builder instance with
a built-in baseUrl. The instance can then be used with non-static
withXxx(...) method alternatives to the static fromXxx(...) methods.

Issue: SPR-12617

Prior to this commit, AnnotationAttributes retrieved from
MetaAnnotationUtils's AnnotationDescriptor could contain attributes
from the wrong annotation if an inherited annotation shadowed a locally
declared composed annotation.

This commit addresses this issue by invoking the new
getAnnotationAttributes() method in AnnotatedElementUtils that provides
a flag to control whether superclasses should be searched -- which
coincidentally processes local annotations before searching the class
hierarchy.

Issue: SPR-12749, SPR-11598

Issue: SPR-12738

Issue: SPR-12738

This commit introduces support in AnnotatedElementUtils for finding
annotations declared on interfaces at the type level.

NB: this commit does not include support for finding annotations
declared on interface methods.

In order to maintain backward compatibility with @Transactional
annotation attribute processing, a new getAnnotationAttributes() method
has been added to AnnotatedElementUtils that provides a flag to control
whether interfaces should be searched.
SpringTransactionAnnotationParser and JtaTransactionAnnotationParser
have been updated accordingly to ensure that interfaces are not
unintentionally searched in the @Transactional resolution process.

This commit also introduces additional tests and updates TODOs for
SPR-12738.

Issue: SPR-12944, SPR-12738

Issue: SPR-12170

This commit adds support for script based templating. Any templating
library running on top of a JSR-223 ScriptEngine that implements
Invocable like Nashorn or JRuby could be used.

For example, in order to render Mustache templates thanks to the Nashorn
Javascript engine provided with Java 8+, you should declare the following
configuration:

@Configuration
@EnableWebMvc
public class MustacheConfig extends WebMvcConfigurerAdapter {

	@Override
	public void configureViewResolvers(ViewResolverRegistry registry) {
		registry.scriptTemplate();
	}

	@Bean
	public ScriptTemplateConfigurer configurer() {
		ScriptTemplateConfigurer configurer = new ScriptTemplateConfigurer();
		configurer.setEngineName("nashorn");
		configurer.setScripts("mustache.js");
		configurer.setRenderObject("Mustache");
		configurer.setRenderFunction("render");
		return configurer;
	}
}

The XML counterpart is:

<beans>
	<mvc:annotation-driven />

	<mvc:view-resolvers>
		<mvc:script-template />
	</mvc:view-resolvers>

	<mvc:script-template-configurer engine-name="nashorn" render-object="Mustache" render-function="render">
		<mvc:script location="mustache.js" />
	</mvc:script-template-configurer>
</beans>

Tested with:
 - Handlebars running on Nashorn
 - Mustache running on Nashorn
 - React running on Nashorn
 - EJS running on Nashorn
 - ERB running on JRuby
 - String templates running on Jython

Issue: SPR-12266

Issue: SPR-12884

Prior to this commit, the search algorithm used by the
findAnnotation(Method, Class) method in AnnotationUtils only found
direct annotations or direct meta-annotations (i.e., one level of
meta-annotations).

This commit reworks the search algorithm so that it supports arbitrary
levels of meta-annotations on methods. To make this possible, a new
findAnnotation(AnnotatedElement, Class) method has been introduced in
AnnotationUtils.

This fix also allows for the @Ignore'd tests in
TransactionalEventListenerTests to be re-enabled.

Issue: SPR-12941

Issue: SPR-12940

Issue: SPR-12939

Since the ContextCache is now a published SPI, it and its collaborators
have been moved to a dedicated 'org.sfw.test.context.cache' subpackage.

Issue: SPR-12683

This is a rework of fd7153ff that also now clears the reference to the
BeanFactory when the context is disposed.

Issue: SPR-12518

Issue: SPR-12597

If a custom MessageConverter is set, it is not used for replies defined
via the Message abstraction. This commit harmonizes the behaviour of the
`MessagingMessageConverter` so that the conversion of the payload can
be converted for both incoming and outgoing messages.

Issue: SPR-12912

Previously, a custom `DestinationResolver` was not made available
to the underlying `MessageListener`: if a reply needs to be sent, the
default `DestinationResolver` was used.

This commit ensures that if a custom `DestinationResolver` has been set,
it is also configured accordingly for replies.

Issue: SPR-12927

Issue: SPR-12931

This commit adds an assertion to DefaultTestContext's
getApplicationContext() method to ensure that a context loaded by the
Spring TestContext Framework (TCF) or retrieved from the ContextCache
is still active. This extra check helps to avoid situations where
developers manually close a cached context instead of relying on the
@DirtiesContext support.

Issue: SPR-12932

The changes made in 0cb22fc8 would
result in contexts not being properly closed if evicted from the
ConcurrentReferenceHashMap by the Garbage Collector.

This commit reverts those changes and returns to using standard
ConcurrentHashMaps for the time being.

Issue: SPR-7687

Issue: SPR-12683

Improve extensibility of TestContext bootstrapping & context caching

These commits include numerous refactorings and enhancements to the
bootstrapping and context caching mechanisms in the Spring TestContext
Framework.

Issue: SPR-12683