Dependencies for json-path in BOM
Fix LoggingApplicationListener

- If `logging.config` is set and could open/read the resource
then, return.
  - Currently, it logs warning though the resource is successfully
read.
Upgrade to Groovy 2.3.4

Closes #1224
Upgrade to HikariCP 1.4.0

Closes #1220
Merge branch '1.1.x'
Merge branch '1.1.x'
Add dependency management for spock-spring and document its use

Closes #1234
Merge branch '1.1.x'
Add OnPropertyValueCondition annotation

This commit adds a new conditional annotation that checks if a
property has a given value. This allows to replace constructs
such as

@ConditionalOnExpression("'${app.myProperty:foo}' == 'foo'")

to

@ConditionalOnPropertyValue(property="app.myProperty",
        value="foo", defaultMatch=true)

Which is definitely more verbose but has the following advantages:

1. Works by default if the actual property in the environment is
   a bit different (i.e. my-property)
2. Works if the value of the property has a diferent case (FoO or
   FOO would match)
3. Gives a precise reporting in the auto configuration report

The defaultMatch flag is meant to mention that the condition should
also match if the value is not set; the auto-config report would
also have an explicit report about it.

Fixes gh-1000
Ensure properties that are not enumerable can be resolved from placeholders

Before this change a property whose key was in a non-enumerable property source would
not resolve placeholders, leading to ${style} values in @ConfigurationProperties beans
even if the placeholders ere resolvable.
Merge branch '1.1.x'
Merge @ConditionalOnPropertyValue

This commit merges the features of @ConditionalOnPropertyValue
to the existing @ConditionalOnProperty.

The "match" attribute provides the value to match against. By default,
the value should not be equal to "false" which is the existing default
of @ConditionalOnProperty. "defaultMatch" specifies if the value
should be present. The default matches also the existing behavior of
@ConditionalOnProperty.

Fixes gh-1000
Replace @ConditionalOnExpression

This commit replaces @ConditionalOnExpression instances that are
checking for a specific value to @ConditionalOnPropertyValue
Ensure order is preserved in Rabbit addresses

Using StringUtils.commaDelimitedListToSet() does not preserve order (why?),
so we have to use commaDelimitedListToStringArray().

Fixes gh-1262
Merge branch '1.1.x'
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 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.

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.

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