Reinject Servlet mocks between TestNG test methods

Prior to this commit, if multiple test methods were executed in a
subclass of AbstractTestNGSpringContextTests annotated with
@WebAppConfiguration, then injected Servlet API mocks would only
reference the mocks created for the first test method. Subsequent test
methods could therefore never reference the current mocks, and there
was a discrepancy between the state of the injected mocks and the mock
set in the RequestContextHolder.

This commit addresses this issue by ensuring that dependencies
(including updated mocks) are injected into the test instance before
the next test method if the ServletTestExecutionListener resets the
request attributes in RequestContextHolder.

Issue: SPR-11626
Remove duplicate @since tags in EmbeddedDatabaseBuilder
Introduce execute(DataSource) in ResrcDbPopulator

To simplify common use cases, this commit introduces a new
execute(DataSource) method in ResourceDatabasePopulator that complements
the existing populate(Connection) method.

Issue: SPR-11629
Fix broken tests in QuartzSupportTests

This commit ensures that QuartzSupportTests and its related
configuration are compatible with Quartz 2.1.7.

 - Test jobs are now durable where required.

 - Deleted legacy tests that attempted to use a Runnable instead of a
   Job as a jobClass for a JobDetail.

 - Replaced quartz-hsql.sql with current version for Quartz 2.1.7.

Issue: SPR-11630
Custom KeyGenerator

This commit adds an extra parameter to the base @Cache method
annotations: keyGenerator. This parameter holds the name of the
KeyGenerator bean to use to compute the key for that specific
caching endpoint.

This gives therefore a third way to customize the key. These are:
1. Default KeyGenerator (global for all endpoints)
2. The 'key' attribute of the annotation, giving the SpEL expression to use
3. The 'keyGenerator' attribute of the annotation

The annotation attributes are therefore exclusive. Trying to specify
them both will result in an IllegalStateException.

The KeyGenerator to use for a given operation is cached on startup
so that multiple calls to it does not resolve the instance to use over and
over again.

Issue: SPR-10629
Add custom cache manager per cache operation

It is now possible to specify the CacheManager to use per operation.
The related cache annotation now has an extra attribute that defines
the name of the CacheManager bean to use.  The cache manager that
was previously used is therefore a 'default' cache manager (i.e. the
one to use if no custom cache manager has been set on the operation).

Issue: SPR-8696
polishing
Provide common cache config

Prior to this commit, common cache operation settings had to be
repeated for every operation: cache name(s), custom cache manager
and custom key manager.

This commit introduces the @CacheConfig annotation to bet set at
class-level (either directly or as a meta-annotation). As the cache
name(s) can be rationalized there, the "value" of the various
annotations are no longer mandatory.

CacheAnnotationParser has an API breakage to be able to retrieve
information at class-level.

Issue: SPR-11316
Improving test coverage of determinePrimaryCandidate

Added tests checking the behaviour of autowiring by type when the @Primary
annotation is present on the class. Fixed also some inconsistencies in the
code.
Add support for @Priority

This commit adds support for @Priority to filter multiple candidates
for autowiring. When multiple candidates are available for a given
bean, the bean annotated with @Primary is used. If none exists, the
one with the higher value for the @Priority annotation is used. If
two beans have the same priority a NoUniqueBeanDefinitionException
is thrown, just as if two beans are annotated with @Primary.

The underlying code for #getBean and #resolveDependency has been
merged as this feature is available for both dependency injection
and bean lookup by type.

Issue: SPR-10548
Created SettableListenableFuture with tests

A SettableListenableFuture implementation of Spring's ListenableFuture
The class is inspired by Google Guava’s
com.google.common.util.concurrent.SettableFuture, but this
implementation uses ReentrantReadWriteLock and CountDownLatch
internally to handle thread synchronization.

Issue: SPR-11614