ContextLoader and FrameworkServlet now use
AnnotationAwareOrderComparator to support @order usage; previously
supported only implementation of the Ordered interface.

Constructors have been added to both FrameworkServlet and
DispatcherServlet to support instance-based programmatic registration
of Servlets within ServletContainerInitializer implementations in
Servlet 3.0+ environments, and more particularly when using Spring 3.1's
WebApplicationInitializer SPI.

This change also renames the method added to FrameworkServlet in
SPR-8185 from #initializeWebApplicationContext to #applyInitializers.
The reason being that a method named #initWebApplicationContext was
already present and the names overlapped confusingly.

Issue: SPR-7672, SPR-8185

GenericWebApplicationContext now implements
ConfigurableWebApplicationContext in order to be compatible with
Framework/DispatcherServlet and ContextLoader/Listener, especially with
regard to changes in SPR-7672 that allow for programmatic use of these
types within Servlet 3.0+ environments.  For the first time, it's now
reasonable to imagine injecting a GWAC into DispatcherServlet; the most
robust way to accommodate this possibility is for GWAC to implement
CWAC.

The implementation is in name only, allowing for interchangable use of
GWAC anywhere, for example, an XWAC could otherwise go.  Methods such
as setConfigLocation will throw UnsupportedOperationException if the
configLocation value actually contains text.  Other methods are
implemented as no-ops or to throw UOE as appropriate.

Issue: SPR-7672

WebApplicationInitializer provides a programmatic alternative to the
traditional WEB-INF/web.xml servlet container deployment descriptor
for Servlet API 3.0+ environments.

This is done by building atop the new ServletContainerInitializer
support in Servlet 3.0. See SpringServletContainerInitializer for
complete details. And see WebApplicationInitializer Javadoc for
typical usage examples.

Issue: SPR-7672

In support of SPR-7672 which will support code-based configuration
alternatives to web.xml using new features in the Servlet 3.0 API.

This upgrade does *not* force Spring users to upgrade to Servlet 3.0
capable containers.  Compatibility with and support for
javax.servlet >= 2.4 remains.

Issue: SPR-7672

Issue: SPR-8314

Calls to AbstractApplicationContext#setParent delegate the parent
context environment to the child.

This ensures that any property sources added to the parent are available
to the child as well as ensuring that any profiles activated are
activated everywhere.

Child contexts may still choose to replace their environment (through an
ApplicationContextInitializer, for example).  In any case, however, in
the root/child web application context relationship established by
ContextLoader + DispatcherServlet, the child is guaranteed to have
already been given the parent environment by the time it is delegated
to any ACIs.

See AbstractApplicationContext#setParent for implementation

See FrameworkServlet#createWebApplicationContext for order in which
setParent then initializeWebApplicationContext are called.

Issue: SPR-8185

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