Issue: SPR-8439

Issue: SPR-7550

[SPR-8395] AnnotationConfigContextLoader now supports default configuration classes with arbitrary names

[SPR-8395][SPR-8386] AnnotationConfigContextLoader now generates a list of default configuration classes by finding all non-private, non-final, static, inner classes of the test class that are annotated with @Configuration; updated JavaDoc in AbstractGenericContextLoader and AnnotationConfigContextLoader to reflect changes resulting from the SmartContextLoader integration.

[SPR-8386] AnnotationConfigContextLoader now only considers static inner classes annotated with @Configuration when generating default configuration classes.

[SPR-8386] Polishing SmartContextLoader SPI; AnnotationConfigContextLoader now only considers static inner classes annotated with @Configuration as configuration classes.

- introduced processContextConfigurationAttributes() method in SmartContextLoader SPI
- refactored AnnotationConfigContextLoader, AbstractContextLoader, AbstractGenericContextLoader, ContextLoaderUtils, and TestContext implementations to take advantage of the SmartContextLoader SPI, MergedContextConfiguration, and ContextConfigurationAttributes
- deleted ResourceTypeAwareContextLoader
- deleted ContextLoaderUtils.LocationsResolver and implementations
- moved context key generation from TestContext to MergedContextConfiguration

Issue: SPR-7750

Prior to this change, AbstractAutowireCapableBeanFactory did not support
a default ParameterNameDiscoverer.  This meant that attempting to use
<constructor-arg name=".."> syntax would fail (with a fairly obscure
exception) as that feature depends on a ParameterNameDiscoverer to
introspect the constructor arguments.

This lack of a default was originally intended to avoid a dependency on
ASM, but now that (a) .asm is a built-in module and (b) .beans has a
non-optional compile-time dependency on .asm, there is no reason not to
provide this default.

The net effect is that in a number of locations throughout the
framework, namely in GenericApplicationContext and
AbstractRefreshableApplicationContext, it is no longer necessary to
explicitly call AACBF#setParameterNameDiscoverer. This also means that
using a naked BeanFactory (likely for testing scenarios) is that much
easier.

Issue: SPR-8184

Issue: SPR-8183

Prior to this change, the Property class introduced in 3.1 M2 validated
read/write property method pairs based on whether their parameter/return
types were equal to one another.  This precluded the valid possibility
of read method that returns a subtype of the write method's parameter
type, and represented a regression against 3.1 M1 and earlier versions.

The implementation now uses isAssignableFrom rather than a straight
equals check against the types.

Issue: SPR-8432

As of SPR-8093, jmxremote_optional.jar is present on the build
server in jre/lib/ext, but it is not by default present on local
developer / user machines, meaning that the build ends up broken
by default.

Issue: SPR-8089, SPR-8093, SPR-8458

Prior to this change, DirectFieldAccessor would ignore fields shadowed
in subclasses, favoring the last field processed, which happens to be
the most super declaration based on the way ReflectionUtils.doWithFields
works.

Because the locally shadowed field may be of a different type that the
superclass declaration, it is most correct to preserve and work with
the shadowed field.

Issue: SPR-8398

Issue: SPR-8341 SPR-8453

Issue: SPR-8390