Spring Framework 4.0 introduced first-class support for a Groovy-based
DSL for defining the beans for an ApplicationContext. However, prior to
this commit, the Spring TestContext Framework (TCF) did not provide any
out-of-the-box support for using Groovy scripts as path-based resource
locations when loading an application context for tests.

This commit addresses this issue by introducing first-class support for
using Groovy scripts to load the ApplicationContext for integration
tests managed by the TCF. Specifically, the following changes have been
made in the TCF to support Groovy scripts.

 - Introduced getResourceSuffixes() in AbstractContextLoader in order
   to support multiple resource suffixes in the default detection
   process. This feature is used by the new Groovy/Xml context loaders.

 - Introduced GenericGroovyXmlContextLoader and
   GenericGroovyXmlWebContextLoader which support both Groovy scripts
   and XML config files for loading bean definitions. Furthermore,
   these loaders support "-context.xml" and "Context.groovy" as
   resource suffixes when detecting defaults. Note that a default XML
   config file will be detected before a default Groovy script.

 - DelegatingSmartContextLoader and WebDelegatingSmartContextLoader now
   use reflection to choose between using GenericGroovyXmlContextLoader
   and GenericGroovyXmlWebContextLoader vs. GenericXmlContextLoader and
   GenericXmlWebContextLoader as their XML loaders, depending on
   whether Groovy is present in the classpath.

 - Groovy scripts can be configured via the 'locations' or 'value'
   attributes of @ContextConfiguration and can be mixed seamlessly with
   XML config files.

Issue: SPR-11233

 - Formatting
 - Suppress warnings
 - Remove unused imports

This is a follow-up on the commit introducing MockMvcConfigurer:
https://github.com/spring-projects/spring-framework/commit/c2b0fac852dd9f865699fb374ad78543767fec05

This commit refines the MockMvcConfigurer contract to use (the new)
ConfigurableMockMvcBuilder hence not requiring downcasting to
AbstractMockMvcBuilder.

The same also no longer passes the "default" RequestBuilder which would
also require a downcast, but rather allows a RequestPostProcessor to be
returned so that a 3rd party framework or application can modify any
property of every performed MockHttpServletRequest.

To make this possible the new SmartRequestBuilder interface separates
request building from request post processing while the new
ConfigurableSmartRequestBuilder allows adding a RequestPostProcessor
to a MockMvcBuilder.

Issue: SPR-11497

Overhauled class-level Javadoc for TransactionalTestExecutionListener:

 - Reorganized content.
 - Added headings to paragraphs.
 - Documented TestTransaction support.

Issue: SPR-11941

Prior to this commit, the support for SQL script execution via @Sql
provided an algorithm for looking up a required
PlatformTransactionManager to use to drive transactions. However, a
transaction manager is not actually required for all testing scenarios.

This commit improves the transaction management support for @Sql so
that SQL scripts can be executed without a transaction if a transaction
manger is not present in the ApplicationContext. The updated algorithm
now supports the following use cases.

 - If a transaction manager and data source are both present (i.e.,
   explicitly specified via the transactionManager and dataSource
   attributes of @SqlConfig or implicitly discovered in the
   ApplicationContext based on conventions), both will be used.

 - If a transaction manager is not explicitly specified and not
   implicitly discovered based on conventions, SQL scripts will be
   executed without a transaction but requiring the presence of a data
   source. If a data source is not present, an exception will be thrown.

 - If a data source is not explicitly specified and not implicitly
   discovered based on conventions, an attempt will be made to retrieve
   it by using reflection to invoke a public method named
   getDataSource() on the transaction manager. If this attempt fails,
   an exception will be thrown.

 - If a data source can be retrieved from the resolved transaction
   manager using reflection, an exception will be thrown if the
   resolved data source is not the data source associated with the
   resolved transaction manager. This helps to avoid possibly
   unintended configuration errors.

 - If @SqlConfig.transactionMode is set to ISOLATED, an exception will
   be thrown if a transaction manager is not present.

Issue: SPR-11911

This commit introduces a test that investigates a claim made on Stack
Overflow regarding context caching in the TestContext Framework (TCF).

Prior to this commit, @Sql provided attributes for configuring the
syntax of the referenced SQL scripts as well as exception handling and
transaction behavior; however, such configuration could not be reused
across @Sql declarations thus requiring developers to copy-and-paste
common configuration and resulting in unnecessary code duplication.

This commit addresses this issue by introducing a new @SqlConfig
annotation that can be used to declare common, global configuration for
SQL scripts that can be reused within a test class hierarchy.

 - Introduced top-level @SqlConfig annotation and extracted
   common configuration attributes from @Sql.

 - @SqlConfig can be used at the class level for common, global config
   or via the new 'config' attribute of @Sql for local config.

 - Introduced MergedSqlConfig as a holder for the merged values from
   local and global @SqlConfig instances. MergedSqlConfig also contains
   the logic for overriding global configuration with local
   configuration.

 - Refactored all attributes of @SqlConfig to be either of type String
   or custom enums in order to support overriding. Empty Strings or
   DEFAULT enum values imply the use of a default or inherited value.

Issue: SPR-11896

Issue: SPR-11497

After some further discussion:

The MVC config simplifies ViewResolver configuration especially where
content negotiation view resolution is involved.

The configuration of the underlying view technology however is kept
completely separate. In the case of the MVC namespace, dedicated
top-level freemarker, velocity, and tiles namespace elements are
provided. In the case of the MVC Java config, applications simply
declare FreeMarkerConfigurer, VelocityConfigurer, or TilesConfigurer
beans respectively.

Issue: SPR-7093

Following the separation of FreeMarker/Velocity/TilesConfigurer-related
configuration via separate interface, simplify and streamline the
view registration helper classes which no longer have much difference
(most are UrlBasedViewResolver's).

Updates to Javadoc and tests.

Issue: SPR-7093

This change improves the support for auto-registration of FreeMarker,
Velocity, and Tiles configuration.

The configuration is now conditional not only based on the classpath
but also based on whether a FreeMarkerConfigurer for example is already
present in the configuration.

This change also introduces FreeMarker~, Velocity~, and
TilesWebMvcConfigurer interfaces for customizing each view technology.

The WebMvcConfigurer can still be used to configure all view resolvers
centrally (including FreeMarker, Velocity, and Tiles) without some
default conifguration, i.e. without the need to use the new
~WebMvcConfigurer interfaces until customizations are required.

Issue: SPR-7093

This commit improves and completes the initial MVC namespace
view resolution implementation. ContentNegotiatingViewResolver
registration is now also supported.

Java Config view resolution support has been added.
FreeMarker, Velocity and Tiles view configurers are registered
depending on the classpath thanks to an ImportSelector.

For both, a default configuration is provided and documented.

Issue: SPR-7093

This change adds a method within the ModelResultMatcher that will allow
a user to assert whether the returned Model has an attribute with a
field that has a specific error associated with it.

Issue: SPR-11971

This commit introduces unit tests that attempt to reproduce the problem
described in Spring Boot issue 885; however, the tests pass and
therefore do not confirm the reported problem.

See: https://github.com/spring-projects/spring-boot/issues/885

Issue: SPR-5079

Historically, Spring's JUnit 3.8 TestCase class hierarchy supported
programmatic transaction management of "test-managed transactions" via
the protected endTransaction() and startNewTransaction() methods in
AbstractTransactionalSpringContextTests.

The Spring TestContext Framework (TCF) was introduced in Spring 2.5 to
supersede the legacy JUnit 3.8 support classes; however, prior to this
commit the TCF has not provided support for programmatically starting
or stopping the test-managed transaction.

This commit introduces a TestTransaction class in the TCF that provides
static utility methods for programmatically interacting with
test-managed transactions. Specifically, the following features are
supported by TestTransaction and its collaborators.

 - End the current test-managed transaction.

 - Start a new test-managed transaction, using the default rollback
   semantics configured via @TransactionConfiguration and @Rollback.

 - Flag the current test-managed transaction to be committed.

 - Flag the current test-managed transaction to be rolled back.

Implementation Details:

 - TransactionContext is now a top-level, package private class.

 - The existing test transaction management logic has been extracted
   from TransactionalTestExecutionListener into TransactionContext.

 - The current TransactionContext is stored in a
   NamedInheritableThreadLocal that is managed by
   TransactionContextHolder.

 - TestTransaction defines the end-user API, interacting with the
   TransactionContextHolder behind the scenes.

 - TransactionalTestExecutionListener now delegates to
   TransactionContext completely for starting and ending transactions.

Issue: SPR-5079

Based on the JSONassert library.

Issue: SPR-10113

Issue: SPR-11822

Issue: SPR-1822