Use @ConfigurationProperties for Spring Batch

Fixes gh-1249
Use @ConfigurationProperties for Thymeleaf

Fixes gh-1250
Use @ConfigurationProperties for Thymeleaf

Add missing properties to complement 6568495

Fixes gh-1250
Missing setter on spring.batch.job.names property

Relates to gh-1249
Remove duplicate dependencies
Config metadata annotation processor

This commit adds an annotation processor that generates a metadata
file at compile time with all the configuration items discovered in the
source code. A configuration item is a property that can be configured
through the environment: it has an id (the property key), a type and
a description. Items are gathered in groups that are identifed by a
common prefix in the key. For instance server.port and server.name are
two keys from the "server" group.

A group has also a type that defines the class in which those
properties are defined. Such type is similar to the output of
java.lang.Class#getName(). Considering a Bar inner class in the
org.foo.Foo class, the compiler returns the type as org.foo.Foo.Bar
while a Class would return org.foo.Foo$Bar. The $ special character
allows to easily identify the root class which is an interesting
feature if a link to the root class should be provided, i.e. for
documentation purposes.

The annotation processor is triggered by the @ConfigurationProperties
and @ConditionalOnProperty annotations.

@ConfigurationProperties can be set on classes and methods. When set
on a class, the regular (JavaBean) properties are processed. The id,
type and description of each item are harvested. The description of the
property is retrieved from the javadoc with the following precedence:
field, getter and setter. The type of the property is taken from
setter, field and getter respectively. Properties defined in the parent
hierarchy are discovered as well.

Some heuristics are applied to detect only available properties with
regard to what the RelaxedDataBinder can do. The following apply:

* With the exception of Map and List, the property type must be a
  concrete type
* If the element type is a map or a list, it is detected as an element
  container and its type is currated so that it is always java.util.Map
  or java.util.List respectivly
* If the element type is defined as a nested class of the current
  configuration class, it is detected as a group and its properties
  are also harvested recursively
* In all other cases, a "simple" property is assumed and it must have
  a getter and a setter

For consistency, the type of a primitive is translated to its wrapper
counter part, i.e. boolean becomes java.lang.Boolean.

When @ConfigurationProperties is set on a method that takes no argument
and return a given type, this type is harvested in a similar manner. In
such a case, the return type of the method should be the most specific
type so that all available properties are harvested. The most obvious
use case is our data source auto-configuration that provides support
for Tomcat, Hikari and Commons DBCP. DataSourceConfigMetadata is
exposing those three types as annotated methods so that all available
items are available as part of the "spring.datasource" group.

When both a method and an entity is annotated with the same prefix, the
items are merged in a single group. If the same items is discovered
several times, its content is merged. For instance, if the original
item does not have a description but a newly discovereed one does, that
description is copied over.

This processor is also abble to hande the @ConditionalOnProperty
annotation; consider the following example:

@ConditionalOnProperty(prefix = "foo", value = {"bar", "biz"})
public class MyAutoConfiguration { ... }

This potentially should register the "foo.bar" and the "foo.biz"
configuration items in the "foo" group. If such items are already
defined through @ConfigurationProperties, nothing happens. Otherwise,
these are either added to the existing group or a new group is
created. Note that no additional information is available for the key,
that is description and type as these are not available.

The config metadata file is generated in json at the
"META-INF/boot/config-metadata.json" standard location. A spearate
standard location exists for metadata that are written manually:
"META-INF/boot/config-manual-metadata.json". This commit defines
such file for metadata that can't be harvested manually.

This json output allows to rebuild a ConfigMetadataRepository that
indexes the groups and items in a hierarchical manner. At any level
in the hierarchy it is possible to retrieve all known items and
groups (by id) as well as all "local" (i.e. first level) ones (by
name). The repository allows to include another instance in order to
merge the content of the current repository with another one.

ConfigMetadataRepositoryJsonLoader eases the task of loading
the content of the configuration metadata, either from the current
classpath at the default locations or from a set of configurable
resources. Manual metadata takes precedence over auto-generated ones.

Such repository facilities crawling the available elements and is a
good base for an auto-completion engine which is the primary goal of
those metadata.

Finally, this commit updates the documentation generation process in
such a way that the table listing all the known configuration items
is generated automatically from the content of the classpath.

Fixes gh-1001