AnnotationConfigApplicationContext and
AnnotationConfigWebApplicationContext both expose #register and #scan
methods as of the completion of SPR-8320. This change introduces a new
interface that declares each of these methods and refactors ACAC and
ACWAC to implement it.

Beyond information value, this is useful for implementors of the
ApplicationContextInitializer interface, in that users may create an ACI
that works consistently across ACAC and ACWAC for standalone (e.g.
testing, batch) or web (e.g. production) use.

Issue: SPR-8365,SPR-8320

Primarily for use in conjunction with ApplicationContextInitializer,
these new #scan and #register methods mirror those in
AnnotationConfigApplicationContext. #setConfigLocation
and #setConfigLocations methods remain for compatibility with
ContextLoader-style initialization, but have been locally overridden
and documented clearly.

AnnotationConfigWebApplicationContext#loadBeanDefinitions Javadoc has
also been updated to explain the processing logic for each of these
potential inputs.

Issue: SPR-8320

FrameworkServlet now has support equivalent to ContextLoader and its
"contextInitializerClasses" context-param introduced in 3.1 M1.

This allows users to specify ApplicationContextInitializers at the root
(ContextLoader) level and/or at the DispatcherServlet level.

Issue: SPR-8366

revised findCommonElement handling within TypeDescriptor.forObject(Object); we now fully introspect the collection elements to resolve the common type.  We also support nested introspection e.g. collections of collections.  Object.class is used to indicate no common type, and TypeDescriptor.NULL is used to indicate a null element value

Issue: SPR-8358,SPR-8186

The following is now possible:

@Configuration
public class AppConfig {
    @Inject DataSource dataSource;

    @Bean
    public MyBean myBean() {
        return new MyBean(dataSource);
    }

    @Configuration
    static class DatabaseConfig {
        @Bean
        DataSource dataSource() {
            return new EmbeddedDatabaseBuilder().build();
        }
    }
}

public static void main(String... args) {
    AnnotationConfigApplicationContext ctx =
        new AnnotationConfigApplicationContext(AppConfig.class);
    ctx.getBean(MyBean.class);     // works
    ctx.getBean(DataSource.class); // works
}

Notice that the @Import annotation was not used and that only AppConfig
was registered against the context. By virtue of the fact that
DatabaseConfig is a member class of AppConfig, it is automatically
registered when AppConfig is registered. This avoids an awkward and
redundant @Import annotation when the relationship is already implicitly
clear.

See @Configuration Javadoc for details.

Issue: SPR-8186

ClassMetadata implementations can now introspect their member (nested)
classes. This will allow for automatic detection of nested
@Configuration types in SPR-8186.

Issue: SPR-8358,SPR-8186

SPR-7353 Respect 'produces' condition in ContentNegotiatingViewResolver, improve selection of more specific media type in a pair

Issue: SPR-8348

Issue: SPR-8348

Issue: SPR-8348

This new hook in the AbstractEnvironment lifecycle allows for more
explicit and predictable customization of property sources by
subclasses.  See Javadoc and existing implementations for detail.

Issue: SPR-8354

AbstractEnvironment and subclasses now register a reserved default
profile named literally 'default' such that with no action on the part
of the user, beans defined against the 'default' profile will be
registered - if no other profiles are explicitly activated.

For example, given the following three files a.xml, b.xml and c.xml:

    a.xml
    -----
    <beans> <!-- no 'profile' attribute -->
        <bean id="a" class="com.acme.A"/>
    </beans>

    b.xml
    -----
    <beans profile="default">
        <bean id="b" class="com.acme.B"/>
    </beans>

    c.xml
    -----
    <beans profile="custom">
        <bean id="c" class="com.acme.C"/>
    </beans>

bootstrapping all of the files in a Spring ApplicationContext as
follows will result in beans 'a' and 'b', but not 'c' being registered:

    ApplicationContext ctx = new GenericXmlApplicationContext();
    ctx.load("a.xml");
    ctx.load("b.xml");
    ctx.load("c.xml");
    ctx.refresh();
    ctx.containsBean("a"); // true
    ctx.containsBean("b"); // true
    ctx.containsBean("c"); // false

whereas activating the 'custom' profile will result in beans 'a' and
'c', but not 'b' being registered:

    ApplicationContext ctx = new GenericXmlApplicationContext();
    ctx.load("a.xml");
    ctx.load("b.xml");
    ctx.load("c.xml");
    ctx.getEnvironment().setActiveProfiles("custom");
    ctx.refresh();
    ctx.containsBean("a"); // true
    ctx.containsBean("b"); // false
    ctx.containsBean("c"); // true

that is, once the 'custom' profile is activated, beans defined against
the the reserved default profile are no longer registered. Beans not
defined against any profile ('a') are always registered regardless of
which profiles are active, and of course beans registered
against specific active profiles ('c') are registered.

The reserved default profile is, in practice, just another 'default
profile', as might be added through calling env.setDefaultProfiles() or
via the 'spring.profiles.default' property.  The only difference is that
the reserved default is added automatically by AbstractEnvironment
implementations.  As such, any call to setDefaultProfiles() or value set
for the 'spring.profiles.default' will override the reserved default
profile.  If a user wishes to add their own default profile while
keeping the reserved default profile as well, it will need to be
explicitly redeclared, e.g.:

    env.addDefaultProfiles("my-default-profile", "default")

The reserved default profile(s) are determined by the value returned
from AbstractEnvironment#getReservedDefaultProfiles().  This protected
method may be overridden by subclasses in order to customize the
set of reserved default profiles.

Issue: SPR-8203

Method is obsolete now that Environment (thus AbstractEnvironment as
well) implements the ConfigurablePropertyResolver interface.

- 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

+ update failing test

+ update failing AJ test

+ 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