Issue: SPR-8348

- removed generics from Cache/CacheManager (they add no value since it's an SPI not API)
+ update docs and tests
+ renamed ConcurrentCacheFactoryBean to ConcurrentMapCacheFactoryBean

- removed AbstractDelegatingCache (a cache is not a map, no need to offer a template)
+ renamed ConcurrentCache to ConcurrentCacheMap

Revert signature of
ConfigurationClassPostProcessor#processConfigBeanDefinitions to its form
found in the 3.0.x line.  Refactorings made during 3.1 development
caused otherwise package-private types such as
ConfigurationClassBeanDefinitionReader to escape through this public
method, causing issues for STS as well as being a general design issue.

Upon review, the refactorings could easily be backed out in favor of a
simpler approach, and this has been done.

This also means that ConfigurationClassBeanDefinitionReader can return
to package-private visibility, and this change has been made as well.

Issue: SPR-8200

Issue: SPR-8200

+ update failing test

+ add missing files (remember to check "show unversioned files")

- eliminate unneeded methods
+ introduced value wrapper (name still to be decided) to avoid cache race conditions
+ improved name consistency

+ remove duplicate class

A subtle issue existed with the way we relied on isCurrentlyInCreation
to determine whether a @Bean method is being called by the container
or by user code.  This worked in most cases, but in the particular
scenario laid out by SPR-8080, this approach was no longer sufficient.

This change introduces a ThreadLocal that contains the factory method
currently being invoked by the container, such that enhanced @Bean
methods can check against it to see if they are being called by the
container or not.  If so, that is the cue that the user-defined @Bean
method implementation should be invoked in order to actually create
the bean for the first time.  If not, then the cached instance of
the already-created bean should be looked up and returned.

See ConfigurationClassPostConstructAndAutowiringTests for
reproduction cases and more detail.

Issue: SPR-8080

If the enclosing environment does not implement ConfigurableEnvironment,
then @PropertySource annotations are ignored because there is no way to
add them to the Environment. Now checking first to see if there are any
@PropertySource annotations present before issuing the warning.

Issue: SPR-8314

Allows a convenient mechanism for contributing a PropertySource to the
enclosing Spring Environment. See @PropertySource Javadoc for
complete details and PropertySourceAnnotationTests for examples.

Issue: SPR-8314

Users may now call #setRequiredProperties(String...) against the
Environment (via its ConfigurablePropertyResolver interface) in order
to indicate which properties must be present.

Environment#validateRequiredProperties() is invoked by
AbstractApplicationContext during the refresh() lifecycle to perform
the actual check and a MissingRequiredPropertiesException is thrown
if the precondition is not satisfied.

Issue: SPR-8323

Add note that nested @Configuration classes must be static.

Declaring @Bean methods as 'static' is now permitted, whereas previously
it raised an exception at @Configuration class validation time.

A static @Bean method can be called by the container without requiring
the instantiation of its declaring @Configuration class. This is
particularly useful when dealing with BeanFactoryPostProcessor beans,
as they can interfere with the standard post-processing lifecycle
necessary to handle @Autowired, @Inject, @Value, @PostConstruct and
other annotations.

static @Bean methods cannot recieve CGLIB enhancement for scoping and
AOP concerns. This is acceptable in BFPP cases as they rarely if ever
need it, and should not in typical cases ever be called by another
@Bean method.  Once invoked by the container, the resulting bean will
be cached as usual, but multiple invocations of the static @Bean method
will result in creation of multiple instances of the bean.

static @Bean methods may not, for obvious reasons, refer to normal
instance @Bean methods, but again this is not likely a concern for BFPP
types. In the rare case that they do need a bean reference, parameter
injection into the static @Bean method is technically an option, but
should be avoided as it will potentially cause premature instantiation
of more beans that the user may have intended.

Note particularly that a WARN-level log message is now issued for any
non-static @Bean method with a return type assignable to BFPP.  This
serves as a strong recommendation to users that they always mark BFPP
@Bean methods as static.

See @Bean Javadoc for complete details.

Issue: SPR-8257, SPR-8269

Prior to this change, @ComponentScan annotations were only processed at
the first level of depth.  Now, the set of bean definitions resulting
from each declaration of @ComponentScan is checked for configuration
classes that declare @ComponentScan, and recursion is performed as
necessary.

Cycles between @ComponentScan declarations are detected as well. See
CircularComponentScanException.

Issue: SPR-8307

Introduce @EnableAsync#order

AsyncAnnotationBeanPostProcessor's 'order' property is now mutable;
@EnableAsync's 'order()' attribute allows for setting it, but must
have a default value, thus uses the new Ordered#NOT_ORDERED
constant - a reserved negative number very unlikely to be otherwise
used that may be interpreted as 'not ordered', useful in annotation
defaulting scenarios where null is not an option.

Introduce first working cut of AsyncConfiguration

Remove AsyncCapability

As a mechanism for setting the 'role' hint on BeanDefinitions created
via component-scanning or @Bean methods.

Consolidating internal bean name and aspect class name constats within
AnnotationConfigUtils to allow access from both the context.config
and context.annotation packages without creating a relationship between
the two of them (they are unrelated leaf nodes in the packaging
currently).

The .transaction module does not have a similar utils class and already
has a relationship from transaction.config -> transaction.annotation,
so placing the constants in .annotation.TransactionManagementCapability
to be referenced by .config.AnnotationDrivenBeanDefinitionParser

Allows @Enable* a layer of indirection for deciding which @Configuration
class(es) to @Import.

The @Import annotation may now accept @Configuration class literals
and/or ImportSelector class literals.

@Configuration classes may implement ImportAware in order to be injected
with the AnnotationMetadata of their @Import'ing class.

Includes the introduction of a new PriorityOrdered
ImportAwareBeanPostProcessor that handles injection of the
importing class metadata.

Includes the introduction of AnnotationUtils#findAllAnnotationAttributes
to support iterating through all annotations declared on a given type
and interrogating each for the presence of a meta-annotation. See tests
for details.

@ComponentScan is now checked for explicitly and handled immediately
when parsing @Configuration classes.

Enables @Profile filtering within ComponentScanBeanDefinitionParser

Feature-related support such as @Feature, @FeatureConfiguration,
and FeatureSpecification types will be replaced by framework-provided
@Configuration classes and convenience annotations such as
@ComponentScan (already exists), @EnableAsync, @EnableScheduling,
@EnableTransactionManagement and others.

Issue: SPR-8012,SPR-8034,SPR-8039,SPR-8188,SPR-8206,SPR-8223,
SPR-8225,SPR-8226,SPR-8227

The overloading necessary to preserve the new signature as well as
the old causes ambiguities leading to deprecation warnings in some
caller scenarios.

Issue: SPR-7901

+ add handling for null arguments to prevent NPE in default key generation

SPR-6416, adding basic conversation object tests, improving the access time of the conversation object