Issue: SPR-16968

Update all classes so that inner classes are always last. Also
ensure that utility classes are always final and have a private
constructor and make exceptions final whenever possible.

Issue: SPR-16968

This commit introduces 2 new @Nullable and @NonNullApi
annotations that leverage JSR 305 (dormant but available via
Findbugs jsr305 dependency and already used by libraries
like OkHttp) meta-annotations to specify explicitly
null-safety of Spring Framework parameters and return values.

In order to avoid adding too much annotations, the
default is set at package level with @NonNullApi and
@Nullable annotations are added when needed at parameter or
return value level. These annotations are intended to be used
on Spring Framework itself but also by other Spring projects.

@Nullable annotations have been introduced based on Javadoc
and search of patterns like "return null;". It is expected that
nullability of Spring Framework API will be polished with
complementary commits.

In practice, this will make the whole Spring Framework API
null-safe for Kotlin projects (when KT-10942 will be fixed)
since Kotlin will be able to leverage these annotations to
know if a parameter or a return value is nullable or not. But
this is also useful for Java developers as well since IntelliJ
IDEA, for example, also understands these annotations to
generate warnings when unsafe nullable usages are detected.

Issue: SPR-15540

Issue: SPR-12643

Issue: SPR-10128

This renaming more intuitively expresses the relationship between
subprojects and the JAR artifacts they produce.

Tracking history across these renames is possible, but it requires
use of the --follow flag to `git log`, for example

    $ git log spring-aop/src/main/java/org/springframework/aop/Advisor.java

will show history up until the renaming event, where

    $ git log --follow spring-aop/src/main/java/org/springframework/aop/Advisor.java

will show history for all changes to the file, before and after the
renaming.

See http://chrisbeams.com/git-diff-across-renamed-directories

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

Revert changes to ParserContext, ReaderContext, and XmlReaderContext

    These changes cause cross-version incompatibilities at tooling time
    -- for instance, an STS version that ships with Spring 3.0.5
    classloads the ParserContext defined in that version, whereas it
    classloads NamespaceHandlers and BeanDefinitionParsers (by default)
    from the user application classpath, which may be building against
    3.1.0. If so, the changes introduced to these types in 3.1.0 are
    incompatible with expectations in the 3.0.5 world and cause all
    manner of problems.  In this case, it was NoSuchMethodError due to
    the newly-added XmlReaderContext.getProblemReporter() method; also
    IncompatibleClassChangeError due to the introduction of the
    ComponentRegistrar interface on ParserContext.

    Each of these problems have been mitigated, though the solutions
    are not ideal. The method mentioned has been removed, and instead
    the problemReporter field is now accessed reflectively.
    ParserContext now no longer implements ComponentRegistrar, and
    rather a ComponentRegistrarAdapter class has been introduced that
    passes method calls through to a ParserContext delegate.

Introduce AbstractSpecificationBeanDefinitionParser

    AbstractSpecificationBeanDefinitionParser has been introduced in
    order to improve the programming model for BeanDefinitionParsers
    that have been refactored to the new FeatureSpecification model.
    This new base class and it's template method implementation of
    parse/doParse ensure that common concerns like (1) adapting a
    ParserContext into a SpecificationContext, (2) setting source and
    source name on the specification, and (3) actually executing the
    specification are all managed by the base class.  The subclass
    implementation of doParse need only actually parse XML, populate
    and return the FeatureSpecification object.  This change removed
    the many duplicate 'createSpecificationContext' methods that had
    been lingering.

Minor improvement to BeanDefinitionReaderUtils API

    Introduced new BeanDefinitionReaderUtils#registerWithGeneratedName
    variant that accepts BeanDefinition as opposed to
    AbstractBeanDefinition, as BeanDefinition is all that is actually
    necessary to satisfy the needs of the method implementation. The
    latter variant accepting AbstractBeanDefinition has been deprecated
    but remains intact and delegates to the new variant in order to
    maintain binary compatibility.

This change broke binary compatibility as evidenced by running
the greenhouse test suite and finding that Spring Integration's
AbstractConsumerEndpointParser.parseInternal fails with
NoSuchMethodError when trying to invoke.

Introduce FeatureSpecification interface and implementations

    FeatureSpecification objects decouple the configuration of
    spring container features from the concern of parsing XML
    namespaces, allowing for reuse in code-based configuration
    (see @Feature* annotations below).

    * ComponentScanSpec
    * TxAnnotationDriven
    * MvcAnnotationDriven
    * MvcDefaultServletHandler
    * MvcResources
    * MvcViewControllers

Refactor associated BeanDefinitionParsers to delegate to new impls above

    The following BeanDefinitionParser implementations now deal only
    with the concern of XML parsing.  Validation is handled by their
    corresponding FeatureSpecification object.  Bean definition creation
    and registration is handled by their corresponding
    FeatureSpecificationExecutor type.

    * ComponentScanBeanDefinitionParser
    * AnnotationDrivenBeanDefinitionParser (tx)
    * AnnotationDrivenBeanDefinitionParser (mvc)
    * DefaultServletHandlerBeanDefinitionParser
    * ResourcesBeanDefinitionParser
    * ViewControllerBeanDefinitionParser

Update AopNamespaceUtils to decouple from XML (DOM API)

    Methods necessary for executing TxAnnotationDriven specification
    (and eventually, the AspectJAutoProxy specification) have been
    added that accept boolean arguments for whether to proxy
    target classes and whether to expose the proxy via threadlocal.

    Methods that accepted and introspected DOM Element objects still
    exist but have been deprecated.

Introduce @FeatureConfiguration classes and @Feature methods

    Allow for creation and configuration of FeatureSpecification objects
    at the user level.  A companion for @Configuration classes allowing
    for completely code-driven configuration of the Spring container.

    See changes in ConfigurationClassPostProcessor for implementation
    details.

    See Feature*Tests for usage examples.

    FeatureTestSuite in .integration-tests is a JUnit test suite designed
    to aggregate all BDP and Feature* related tests for a convenient way
    to confirm that Feature-related changes don't break anything.
    Uncomment this test and execute from Eclipse / IDEA. Due to classpath
    issues, this cannot be compiled by Ant/Ivy at the command line.

Introduce @FeatureAnnotation meta-annotation and @ComponentScan impl

    @FeatureAnnotation provides an alternate mechanism for creating
    and executing FeatureSpecification objects.  See @ComponentScan
    and its corresponding ComponentScanAnnotationParser implementation
    for details.  See ComponentScanAnnotationIntegrationTests for usage
    examples

Introduce Default[Formatting]ConversionService implementations

    Allows for convenient instantiation of ConversionService objects
    containing defaults appropriate for most environments.  Replaces
    similar support originally in ConversionServiceFactory (which is now
    deprecated). This change was justified by the need to avoid use
    of FactoryBeans in @Configuration classes (such as
    FormattingConversionServiceFactoryBean). It is strongly preferred
    that users simply instantiate and configure the objects that underlie
    our FactoryBeans. In the case of the ConversionService types, the
    easiest way to do this is to create Default* subtypes. This also
    follows convention with the rest of the framework.

Minor updates to util classes

    All in service of changes above. See diffs for self-explanatory
    details.

    * BeanUtils
    * ObjectUtils
    * ReflectionUtils

EL container integration; support for contextual objects; removal of deprecated Spring 2.0 functionality; Java 5 code style