Issue: SPR-12181

Prior to this commit, given an enum which implements some interface,
GenericConversionService would select the String -> Enum converter even
if a converter for String -> SomeInterface was registered.  This also
affected converters that were registered for String ->
SomeBaseInterface, when SomeInterface extended SomeBaseInterface.

This change modifies the behavior of the private method
getClassHierarchy() by placing Enum.class as late as possible, pretty
much the same way as Object.class is handled.

Issue: SPR-12050

Issue: SPR-11369

GenericConversionService matches converters by full generic target type, allowing for the registration of multiple converters from the same source type to different collection types

Issue: SPR-11369

Move code from spring-build-junit into spring-core/src/test along with
several other test utility classes. This commit removes the temporary
spring-build-junit project introduced in commit
b083bbde.

Make use of the new JUnit functionality introduced in the previous
commit to 'Assume' that perfomance- and timing-sensitive tests should
run only when TestGroup.PERFORMANCE is selected, i.e. when
-PtestGroups="performance" has been provided at the Gradle command line.

The net effect is that these tests are now ignored by default, which
will result in far fewer false-negative CI build failures due to
resource contention and other external factors that cause slowdowns.

We will set up a dedicated performance CI build to run these tests on
an isolated machine, etc.

Issue: SPR-9984

Issue: SPR-10129

Previously the algorithm used by GenericConversionService to find
converters incorrectly searched for interfaces working up from the
base class. This caused particular problems with custom List
converters as as the Collection interface would be considered before
the List interface giving CollectionToObjectConverter precedence
over the custom converter.

The updated algorithm restores the class search order to behave in the
same way as Spring 3.1.

Issue: SPR-10116
Backport-Issue: SPR-10117
Backport-Commit: aa914497

Previously the algorithm used by GenericConversionService to find
converters incorrectly searched for interfaces working up from the
base class. This caused particular problems with custom List
converters as as the Collection interface would be considered before
the List interface giving CollectionToObjectConverter precedence
over the custom converter.

The updated algorithm restores the class search order to behave in the
same way as Spring 3.1.

Issue: SPR-10116

Bypass ObjectToObject conversion when source and object types are
identical and protect against a null source object.

Prior to this commit the TypeDescriptor was used to determine if
conversion was necessary.  This caused issues when comparing a
descriptor with annotations to one without.  The updated code
now compares using TypeDescriptor.getType().

The ObjectToObject converter will now no longer attempt to convert
null source objects.

Issue: SPR-9933

Content:

 - Rename Conditional{Conversion=>Converter}
 - Add @since tags where appropriate
 - Update Apache date headers to read 2002-2012 (not just 2012)
 - Correct minor Javadoc typo

Style:

 - Polish line breaks / whitespace
 - Use wildcard static imports where appropriate

Issue: SPR-9566, SPR-9692, SPR-9928, SPR-9927

EnumToStringConverter in now conditional and only matches Enums that
do not implement interfaces that can be converted.

Issue: SPR-9692

Prior to this commit conversion between like types would often result in
a copy of the object. This can be problematic in the case of large byte
arrays and objects that do not have a default constructor.

The ConversionService SPI now includes canBypassConvert methods that can
be used to deduce when conversion is not needed. Several existing
converters have been updated to ensure they only apply when source and
target types differ.

This change introduces new methods to the ConversionService that will
break existing implementations. However, it anticipated that most users
are consuming the ConversionService interface rather then extending it.

Issue: SPR-9566

Introduce new ConditionalConversion interface that can be applied to
Converter, ConverterFactory or GenericConverter interfaces to make
them conditional. Prior to this commit the only
ConditionalGenericConverter could be conditional.

Issue: SPR-9928

Conversion to and from UUID objects is now supported by the
DefaultConversionService.

Issue: SPR-9765

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

SPR-8718 Prevent ClassCastException when the target of Converter<?,?> is a super-class of the actual target.

implemented collection/map converter conditional matching checks; updated SpEL to reflect this behavior

removed ConversionService/TypeConverter convenience methods in order to restore 3.0's SPI (for backwards compatibility with implementers)

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

added initial support for handling unknown nested type values when converting collections; now favor factory method for constructing nested type descriptors for clarity (made constructor private); improved javadoc