Exclude commons-logging from starter POMs

Update all relevant starter POMs to include a `spring-core` dependency
with an exclusion on `commons-logging`. This prevents `commons-logging`
and `jcl-over-slf4j` from both being on the classpath.

Also add enforcer rules to ensure that commons-logging doesn't sneak
back in, and that there is no dependency convergence. (some additional
libraries were required in spring-boot-dependencies)

Tested with a sample maven project as well as using the `spring jar`
command.

Fixes gh-985
Make WebRequestTraceFilter once per request
Add support for Elasticsearch

Add auto-configuration and starters for Elasticsearch.

Fixes gh-408
Add Elasticsearch tests

Add unit tests for elasticsearch packages. Also refactor some
of the existing tests to prevent Repository clashes.

See gh-408
Add Elasticsearch appendix links

See gh-408
Merge branch 'gh-408'
Fix broken documentation links
Restore test classes

Restore test classes accidentally deleted and ignored in c43fd04f3e.
Fixup POM errors
Create JMS sub-packages

Reorganize the `jms` package into `hornetq` and `activemq` sub-pacakges.

Fixes gh-1005
Add more enforcer rules
Fix grape -> compiler package tangle

Fix package tangle by moving DependencyResolutionContext from the
compiler package to grape.

See gh-1004
Fix CLI command/option package tangle

Fix package tangle in CLI my extracting ExitStatus to a status package.

See gh-1004
Add spring-boot-versions to the full build
Add spring-boot-versions to the prepare profile
Remove some compiler warnings
Defer SQL initialization to fit with JPA better

Added 2 new spring.datasource.* properties ("data" like
"schema", and "deferDdl" like the "spring.jpa.hibernate.*"
flag). The SQL scripts are then run separately and the "data"
ones are triggered by a new DataSourceInitializedEvent,
which is also published by the Hibernate DDL schema export.

Fixes gh-1006
Ensure JPA/Security are not fighting with each other on startup

This is *really* nasty (and led me to discover a related bug
https://jira.spring.io/browse/SPR-11844), but fortunately easy to
hide from users once you have a test case.

The problem is that Spring Security registers a `BeanPostProcessor`
to handle `GlobalAuthenticationConfigurerAdapters`, and Boot
registers a `BeanPostProcessor` to handle injecting the packages
to scan into an `EntityManagerFactory` from `@EntityScan`. The
clash comes because the `EntityScanBeanPostProcessor` wants to be
postprocessed by the Security postprocessor, but if the Security
configuration depends on JPA it won't be ready in time.

The fix (or workaround) depending on how you look at it is to
prevent the other bean post processors from taking an interest in
`EntityScanBeanPostProcessor` at all (mark it as synthetic).

Fixes gh-1008
Defensive on startup with Multipart config
Compiler warnings