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 pull request adds a build-time check for split packages to the Spring
framework build. It allow packages to be split across projects which will
be merged into a single JAR file. It makes split package detection a
dependency of the 'check' task, which is idiomatic gradle as well as allowing
the 'test' task (another dependency of 'check') to be executed without split
packages being detected.

The split package detection logic is structured as a gradle plugin. Thanks
to Rob Winch for contributing the corresponding commit in this pull request.

The project spring-instrument-tomcat is omitted from the split package
check on the basis of SPR-10150. If SPR-10150 is fixed, the project
should be added back into the list of projects to check. This has been noted
in SPR-10150.

Issues: SPR-9990, SPR-10150

No CLA is necessary for the authors of the commits in this pull request since
they are employees of VMware Inc.