Switch master to 1.2.0.BUILD-SNAPSHOT
Move Spring Social and Spring Mobile configuration

This commit uses dedicated Properties classes instead of accessing
the raw environment for Spring Social and Spring Mobile. This
improves the readability and the discovery of such properties.

Fixes gh-1238
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.

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.

When both a method and an entity is annotated with the same prefix, the
items are merged in a single group. Items found in an entity takes
precedence to eventual duplicates found via an annotated method.

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.

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). 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.

Fixes gh-1001