Use null instead of 'none' for ddlAuto

Fixes gh-1012
Add short docs for new Spring Data projects

Fixes gh-1011
pool -> pool2
Add notes for JNDI property values

Fixes gh-999
Remove reference of mvnDebug

The maven plugin now forks a process to start the application so
mvnDebug cannot be used anymore. This commit replaces the reference
of mvnDebug to a link to an example of the maven plugin.

Fixes gh-992
Fix HealthIndicator documentation

fixes #1018
Add example for openshift deployment

Fixes gh-668 (if the asciicdoc compiles)
Check for existence of ResourceBundle before creating MessageSource

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
Initialize DependencyResolutionContext with default dependency mgmt

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
Update dependencies to latest maintenance releases

Despite Javassist 3.18.2-GA being available, it has not be upgraded.
This is to keep it in sync with Hibernate.
Make ElasticSearchAutoConfiguration conditional on SD Elasticsearch

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
Revert deferred DDL changes and re-oreder database migrations

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
Add missing entries to the tables of auto-configuration classes

Closes #998
Cross link Actuator and User Guide docs

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
Add documentation for JMS support

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

Fixes gh-1026
Exclude commons-logging to the extent that even Gradle’s happy

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
Fix numbering of items in list of steps for Openshift deployment

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
Add explicit dependencies to make Gradle pull in the desired version

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
Make HypermediaAutoConfiguration more lenient.

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.
Use an embed HornetQ broker by default

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