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 space indentation with tabs

Issue: SPR-9990
Refactor detect-split-packages Gradle plugin

 - Use conventional plugin naming, i.e. "detect-split-packages" instead
   of applying plugin based on fully-qualified class name

 - Rename "diagnose" => "detect" consistently throughout plugin, task
   and method names and generally refactor naming throughout to follow
   "detect split packages" phrasing

 - Add Javadoc to DetectSplitPackagesPlugin

 - Improve error reporting when split packages are detected

   Upon detecting one or more split packages, `detectSplitPackages` now
   fails idiomatically, throwing a GradleException to signal task failure
   (as opposed to the previous approach of using an assert assertion), and
   the output reads as follows:

       $ gradle detectSplitPackages
       [...]
       :buildSrc:build UP-TO-DATE
       :detectSplitPackages FAILED

       FAILURE: Build failed with an exception.

       * What went wrong:
       Execution failed for task ':detectSplitPackages'.
       > The following split package(s) have been detected:
          - org.springframework.beans (split across spring-beans and spring-orm)
          - org.springframework.core.env (split across spring-context and spring-core)

 - DetectSplitPackagesTask now automatically attaches itself to `check`
   task lifecycle if the enclosing project contains a `check` task

 - DetectSplitPackagesTask adds itself to the 'Verification' task group,
   ensuring that it shows up correctly in `gradle tasks` task listings

 - packagesToScan now defaults to all subprojects; users may then
   customize this by removing individual subprojects from the collection

Issue: SPR-9990
Merge pull request #214 from glyn/SPR-9990

# By Chris Beams (2) and others
* SPR-9990:
  Refactor detect-split-packages Gradle plugin
  Replace space indentation with tabs
  Rework split package detection code
  Example SplitPackageDetectorPlugin
  Detect split packages at build time