Rename a few classes and methods relating to DataSourceInitialization
and update the DataSourceInitializedPublisher to check for Hibernate
settings.

It was doing scary things (like starting elasticsearch, hornetq etc).
There's still an outstanding question about why the context was
not being properly closed in such a scenario (maybe one of those
embedded servers lurking on a background thread?).

See gh-1034

They all want to create an MBeanServer and when that happens
user sees no MBeans, or sometimes just one set (Spring Core,
Spring Integration or Spring Boot). To harmonise them we
create a @Bean of type MBeanServer and link to it in the
other autoconfigs

Fixes gh-1046

We now register the Jackson JodaTime module with Jackson ObjectMappers
if it is on the classpath. We also register the JSR-310 module if it's
on the classpath and the application is running Java 8 or better.

Extracted the Jackson specific configuration previously residing in
HttpMessageConvertersAutoConfiguration into a JacksonAutoConfiguration
class.

Added the Jackson JSR-310 module as a managed Boot dependency.

Added a new @ConditionalOnJava annotation that allows to conditionally
enable configuration based on the Java version that is running. 

The annotation currently supports two modes of restricting Java versions:
the default mode checks for a Java version equal or better than the
requested one. Beyond that it can be configured to only match if Java
version is older than the configured one.

We've had problems with the starters when used with Gradle. They have
been pulling in commons-logging (#987) and the wrong version of Spring
(#1028) due to Gradle's different exclusion and dependency resolution
semantics.

This commit adds some integration tests that use Gradle's tooling API
to take each starter in turn and build a Gradle project that depends
upon it. The build looks at the transitive dependencies and checks
that neither commons-logging nor any Spring modules with the wrong
version are present.

Closes #1036

Fixes gh-1041

Fixes gh-958

* bom-janino:
  Added Janino to BOM.

It didn't make sense not to do anything at all if a Reactor @Bean
was detected, so now we only back off creating the rootReactor if
one is present.

This commit is an attempt to fix the build failures with the HornetQ
tests and relates to #1034

- Remove ;
- Remove unnecessary public modifiers
- Remove unnecessary .class suffixes

Fixes gh-1032

We also convert the SpringBootPlugin to be .groovy to ease defaulting
the encoding to UTF-8. We do not make the file any "more groovy" to leave
this to a distinct commit.

There were some residual issues to do with the changes to the implementation
of security.basic.enabled=false. It was a good idea to have a filetr chain
triggered by the flag being off because it smooths the way for user-defined
filter chains to use the Boot AuthenticationManager (as a first step at least),
but it wasn't a goog idea to add any actual secuity features to that filter.
E.g. if it has HSTS then even an app like Sagan that has some secure endpoints
that it manages itself and the rest is unsecured has issues because it can't
accept connections over HTTP even on unsecure endpoints.

TODO: find a way for security.ssl_enabled=true to apply to only the user-
defined security filter (maybe not possible or worth the effort, since they
can inject a SecurityProperties if they need it?).

See gh-928

This commit changes the default behavior of the HornetQ auto
configuration. Prior to this commit, an embedded broker was only
started when it was requested explicitly by a configuration option.

This is inconsistent with the ActiveMQ support and boot favors the
easiest route. If the necessary classes are available, HornetQ is
embedded in the application by default.

Fixes gh-1029

HypermediaAutoConfiguration didn't consider an @EnableHypermediaSupport 
annotation being present in the user configuration which could've caused 
it to be evaluated twice.

This is especially the case if both the auto-configuration for Spring 
HATEOAS and Spring Data REST kick in as Spring Data REST actively declares
@EnableHypermediaSupport. The double evaluation then causes injection
ambiguities as we now get multiple beans of e.g. LinkDiscoverers deployed.

Due to the lack of dependency management in Gradle a number of the
starters were pulling in old versions of spring-tx (and in some cases
spring-context-support as well) as the only dependency was a
transitive one that pulled in an older version.

This commit adds explicit dependencies on spring-context-support and
spring-tx where appropriate. These dependencies will specify Boot's
preferred version of Spring causing Gradle to do the right thing as it
prefers the latest version of a dependency when there is more than one
to choose from.

Fixes #1028

The list continuation character '+' can be used to prevent a blank
line from ending a list, thereby allowing code blocks to be included
in a list. See "Complex content in outline lists" [1] for more
details.

[1] http://asciidoctor.org/docs/asciidoc-syntax-quick-reference/#lists

Fixes #1025

Gradle hasn’t different exclusion semantics to Maven. In Maven you can
exclude spring-core’s commons-logging dependency once and it’ll be
honoured even if you have multiple transitive routes to commons-logging
via spring-core. In Gradle you have to exclude commons-logging from
everything that has a transitive spring-core dependency. To make matters
worse this doesn’t only apply to dependencies and exclusions declared in
build.gradle but also to dependencies and exclusions declared in the pom
files of the artifacts that a Gradle build depends upon.

In short, to make our starters work as intended with Gradle, this commit
adds many, many exclusions for commons-logging. It also removes
commons-logging exclusions from spring-boot-dependencies’
<dependencyManagement> as they have no effect with Gradle and their
presence can cause us to miss required exclusions in a starter

Fixes #987

This commit documents Boot's JMS support, in particular how Boot
can auto-configure the ConnectionFactory for ActiveMQ and
HornetQ.

Fixes gh-1026

Not having READMEs in github is a mistake IMO, so here's one
restored and with a link to the docs. Docs also updated to
more accurately reflect the location of the actuator features
in implementation.

See https://github.com/spring-guides/gs-actuator-service/pull/7
for the Getting started guide change

Fixes gh-1014

Closes #998

Schema initialization now happens in @PostConstruct (effectively)
whether it is via the Hibernate EntityManagerFactory or the
Boot DataSourceInitialization (in addition or instead). The data.sql
script if it exists is still executed on an event fired from the
other places, so those tests are passing.

Flyway and liquibase have bean factory post processors (like
the one they use to order the audit aspect in Spring Data) that
enforce a dependency on those components from the EntityManagerFactory.
So Hibernate validation is still happy (and there are 2 tests to
prove it now as well).

Fixes gh-1022

ElasticSearchAutoConfiguration depends on two Spring Data Elasticsearch
classes (TransportClientFactoryBean and NodeClientFactoryBean), however
it’s only conditional on Elasticsearch itself being on the classpath.
This lead to start up failures due to a ClassNotFoundException. Its
@ConditionalOnClass configuration has been updated so that the
auto-configuration will only be enabled if both Elasticsearch and Spring
Data Elasticsearch are on the classpath.

The dependencies on TransportClientFactoryBean and NodeClientFactoryBean
were ‘hidden’ in ElasticsearchProperties. The logic that uses these
types has been moved into ElasticSearchAutoConfiguration so that the
usage of the types and the related @ConditionalOnClass configuration
is in the same file.

Fixes #1023

Despite Javassist 3.18.2-GA being available, it has not be upgraded.
This is to keep it in sync with Hibernate.

In the absence of a @GrabMetadata annotation,
DependencyResolutionContext provided no dependency management. This
was leading to incorrect dependency versions being pulled in. This
commit intializes the context with default dependency management that
will be replaced should @GrabMetadata be encountered.

Fixes #1021

Irritatingly a ResourceBundleMessageSource never gives up trying to
create a resource bundle for every message resolution, so to stop
it logging all those warnings (and probably sucking performance-wise)
we need to disable the MessageSource if a bundle is not provided.

Fixes gh-1019

Fixes gh-668 (if the asciicdoc compiles)

fixes #1018