Merge branch 'cleanup-3.2.x' into SPR-10126

* cleanup-3.2.x: (37 commits)
  Eliminate AJ @Async warning in test case
  Update Apache license headers for moved files
  Move namespace tests to root integration module
  Fix several miscellaneous compiler/Eclipse warnings
  Remove duplicate test resources
  Fix warnings due to unused import statements
  Update Apache license headers for affected sources
  Remove duplicate test classes
  Replace test beans with test objects
  Polish test sourceSet dependencies
  Add test dependencies sources for testCompile
  Use unmodified 'version' when not on a topic branch
  Enable execution of TestNG tests in spring-test
  Polish support for topic branch-specific versions
  Segregate add'l long-running and performance tests
  Eliminate EBR dependencies and repository config
  Skip creation of IDEA metadata for spring-aspects
  Fix Eclipse compilation error in Gradle plugin
  Polish build.gradle
  Recursively add test dependencies
  ...
Detect split packages at build time

Split packages are a well-known anti-pattern for OSGi and a blocker for
Eclipse Virgo (which prevents split packages being accessed via its
Import-Library construct).

Split packages are also unhelpful with a traditional linear classpath
as a split package name does not uniquely identify the Spring framework
JAR from which it came, thus complicating problem diagnosis and
maintenance.

Juergen Hoeller supports this position in the following comment in
SPR-9990:

>FWIW, I generally find split packages a bad practice, even without
>OSGi in the mix. For the Spring Framework codebase, I consider a
>split-package arrangement a design accident that we want to detect
>in any case - and that we're willing to fix if it happened.
>
>I'm actually equally concerned about the source perspective: After
>all, we want a package to be comprehensible from a single glance
>at the project, not requiring the developer to jump into several
>source modules to understand the overall layout of a package.

Split packages have crept into Spring framework twice in recent months
- see SPR-9811 and SPR-9988. Currently, they are only detected once
the Spring framework has been converted to OSGi bundles and these
bundles have been tested with Eclipse Virgo.

This commit adds a build-time check for split packages to the Spring
framework build.

Issue: SPR-9990

Conflicts:

	build.gradle
Example SplitPackageDetectorPlugin
Rework split package detection code

Allow packages to be split across projects which will be merged into a
single JAR file.

Make split package detection a dependency of the 'check' task. This
is idiomatic gradle as well as allowing the 'test' task (another
dependency of 'check') to be executed without split packages being
detected.

Omit the project spring-instructment-tomcat from the check on the basis
of SPR-10150.

Issues: SPR-9990, SPR-10150

Conflicts:

	build.gradle
Replace EasyMock with Mockito in spring-orm

Issue: SPR-10126
Merge branch 'SPR-10126' into cleanup-3.2.x

* SPR-10126:
  Replace EasyMock with Mockito in spring-orm
Merge branch 'cleanup-3.2.x' into 3.2.x

* cleanup-3.2.x:
  Replace EasyMock with Mockito in spring-orm
Ensure JUnit & TestNG tests run in spring-test

Prior to this commit, the Gradle build configuration only executed
TestNG-based tests and effectively disabled all JUnit-based tests in the
spring-test module. Furthermore, TestNG-based tests were not properly
reported in Bamboo CI builds.

This commit ensures that both JUnit and TestNG tests are executed in the
Gradle build by defining a new testNG task within the spring-test
configuration. The test task now depends on the new testNG task.
Furthermore, the testNG task makes use of Gradle 1.3's support for
generating test reports for TestNG tests alongside reports for JUnit
tests. The net effect is that all tests are executed and reportedly
properly in Bamboo builds on the CI server.

- Enabled both JUnit and TestNG tests for the spring-test module.
- Corrected bugs in FailingBeforeAndAfterMethodsTests introduced in
  commit 3d1b3868fe3b38f5552883f54111c53f6ee75572.
- Deleted the now obsolete SPR-9398.txt file.

Issue: SPR-9398
Marked LocalCacheProviderProxy as deprecated (following Hibernate 3.3.'s CacheProvider deprecation)
MessageSourceResourceBundle overrides JDK 1.6 containsKey method, avoiding NPE in getKeys

Issue: SPR-10136
AbstractAdvisingBeanPostProcessor caches per bean target class, working for null bean names as well

Issue: SPR-10144
MimeMessageHelper encodes attachment filename if not ASCII compliant

Issue: SPR-9258
FreeMarkerConfigurationFactory properly supports TemplateLoaders when recreating Configurations

Issue: SPR-9389
SpringContextResourceAdapter implements equals/hashCode according to the JCA 1.5 contract

Issue: SPR-9162
Added dedicated sort method to AnnotationAwareOrderComparator

Issue: SPR-9625
AnnotationAwareOrderComparator is able to sort Class objects as well

Issue: SPR-10152
AnnotationAwareOrderComparator etc
Polish Javadoc in CookieValue and RequestHeader
Use explicit JDK versions in aspects.gradle

Previously aspects.gradle used the Gradle conventions for the source
and target compatibility. This means that unless the conventions were
updated the current JDK would be used for both source and target
compatibilty. Since an update to build.gradle changed to configure the
compileJava and compileTestJava tasks explicitly spring-aspects has
been compiled with JDK 7 compatibility.

This commit explicitly uses the source and target compatibility from
spring-core to ensure that aspects.gradle is kept up to date.

Issue: SPR-10161
Update Javadoc for MockMvc

Deleted reference to the obsolete configureWarRootDir() method from the
stand-alone spring-test-mvc project.