Allow custom dependency metadata to be used with the CLI

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
Add config hint to template error messages
Improved integration with Groovy 2.3.1

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

Fixes gh-890
Add more detail to error handling docs
Use Flyway to bind flyway.*

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
Update Spring Batch to 3.0.0.RC2

Fixes gh-800
Re-order condition that checks for anonymous class

Workaround for ASM 5.0.2 bug that fixes gh-904
Enhance Groovy template support in CLI

to allow user to specify the TemplateEngine

Fixes gh-908
Add sample project for Groovy templates
Polish dependency management

- Remove dependency management for projects that Boot does not have a
  runtime dependency upon
- Provide dependency management for all of Spring Batch’s modules
Fix name of Groovy Templates sample project
Use spring-boot-dependencies as spring-boot-dependency-tools' parent

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
Include details of dependency versions in the docs

Closes #637
Fix ordering problem with Mongo autoconfig
Polish dependency management again

Remove declarations for the Spring OAuth modules that should have
been removed as part of eeefbdd5
Polish
Add spring-boot-versions project

Add a new maven project containing a versions.properties file and
an effective POM. Rework existing projects to use the versions
artifacts.

Partially reverts 307fbba9e4b88ea9938817a64d840d82d6a8cd72

Fixes gh-913
Fix broken relative path
Remove reference to resolved issues in Groovy