Previously spring-boot-dependency-tools used spring-boot-tools as its
parent. This meant that it inherited spring-boot-parents' dependency
management that we did not want to expose to applications. The
solution to this was to generate the effective pom and then filter
out any thing that did not appear in spring-boot-dependencies' pom.
This filtering had to unwanted side-effect of breaking bom imports:
the effective pom would contain the dependency management from the
imported bom, but this would be filtered out as the entries didn't
appear in spring-boot-dependencies' pom.

This commit updates spring-boot-dependency-tools to use
spring-boot-dependencies as its parent. This means that its effective
pom contains the desired dependency management and nothing more,
allowing the filtering logic to be removed.

The use of Spring Security's bom has been reinstated as it will now
work as intended and versions for its modules will be available in the
CLI and via the Gradle plugin.

Closes #825
Fixes #838

- Remove dependency management for projects that Boot does not have a
  runtime dependency upon
- Provide dependency management for all of Spring Batch’s modules

to allow user to specify the TemplateEngine

Fixes gh-908

Workaround for ASM 5.0.2 bug that fixes gh-904

Fixes gh-800

Since Flyway has bean properties (with getters and setters)
it can be used to bin directly to the Environment (instead of
copying all the properties into FlywayProperties).

Fixes gh-806

Fixes gh-890

Groovy 2.3.1 has a new template loader abstraction that handles
compiler caching (better performance by factor of 10).

Add support for a new annotation, @GrabMetadata, that can be used
to provide the coordinates of one or more properties files, such as
the one published by Spring IO Platform, as a source of dependency
metadata. For example:

@GrabMetadata("com.example:metadata:1.0.0")

The referenced properties files must be in the format
group:module=version.

Limitations:

 - Only a single @GrabMetadata annotation is supported
 - The referenced properties file must be accessible in one of the
   default repositories, i.e. it cannot be accessed in a repository
   that's added using @GrabResolver

Closes #814

Moved into EndpointAutoConfiguration

* pull899:
  Exact match for groupId excludes

Previous to this commit, any groupId starting with one of the
configured exclude would be excluded as well. This potentially
leads to unintentional dependency filtering: for example the
GroupIdFilter with an exclusion of "org.springframework"
also removes "org.springframework.boot" dependencies.

Add MatchingGroupIdFilter that uses an exact match instead.

See #649

Uses known databases from org.flywaydb.core.internal.util.jdbc.DriverDataSource

Fixes gh-824, fixes gh-809

A callback is added in autoconfig, so that if users inject the EntityManagerFactoryBuilder
into their app and use it to create multiple EntityManagerFactories, they all get the
same deferred DDL behaviour. The deferred DDL can also be disabled by setting
spring.jpa.hibernate.deferDdl=true.

Fixes gh-894

The EntityManagerFactory will happily process the DDL on startup, but
that happens too early (because of LoadtimeWeaverAware processing). We
can defer it to a more civilised stage, e.g. ContextRefreshedEvent by
using the Hibernate native APIs directly.

It makes the JpaProperties slightly more complex because they need
to distinguish between the early init and late processing versions
of the Hibernate properties.

Not ready for prime time yet because there is no way to deal with
multiple EntityManagers.

Fixes gh-894

Fixes gh-892

Fixes gh-616

Conflicts:
	spring-boot-dependencies/pom.xml
	spring-boot-tools/spring-boot-loader/src/test/java/org/springframework/boot/loader/jar/JarFileTests.java

Update JarFile to correctly create system independent URLs to prevent
potential URISyntaxExceptions when running on Windows.

Fixes gh-836

The problem all along has been in AsciiBytes, so the fix in
commit ce3aaf was just a stop gap for a system where multi-byte
characters are supported but the default encoding is not UTF-8 (e.g.
most Windows systems). The real solution is not to leave it to
chance and always pick an encoding for the JarEntry names (i.e.
in AsciiBytes).

(Cherry picked from commit 06e364a9)

Fixes gh-764

Update run tasks to ensure that only a single main class is required
when performing a class search.

See gh-886

Since groovy-templates is included with groovy-all it is unreasonable
to expect anyone who has it on their classpath to have resolvable templates.
We may need to revisit this decision, but since the origain feature
that drove this was thymeleaf and idaiotic users having it on their
classpath but not using it, maybe we don't need to.

Default suffix .tpl. If groovy-templates is on the classpath user
can now add templates and get them rendered and resolved in an MVC
app.

TODO: Macro helpers for message rendering etc.

See gh-878