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 one or more types and each item defines to which group
type(s) it belongs to. This allows to precisely identify which
properties are available when a set of subtypes are parsed. A typical
example is "spring.datasource" that can be configured against different
supported data source types. Most properties are common (and therefore
linked to all group types) but others are specific to one or two
implementations.

The String representation of the 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.

Elements in the metadata are to be defined in standard camel case
format. Root groups may use dots to separate logical elements even
there is not parent group to represent them.

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 Collection, the property type must be a
  concrete type
* If the element type is a map or a collection, it is detected as an
  element container and its type is currated so that it is always
  java.util.Map or java.util.Collection 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 item 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 able 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. Note that
conditions may use another format (hypen) in particular. Such format
is automatically handled and the elements are transformed to camel
case if necessary.

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.

The 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