Modify @Condition for detecting existing message bundle resource

The problem with the old code is that it worces a ResourceBundle to
initialize with the default encoding (and that is then cached in the
JDK) during @Condition evaluation (so before the encoding is known).

Includes test for swedish messages

Fixes gh-1228
Ensure embedded containers actually stop if there is an error on startup

Both embedded containers need to be checked after starting to ensure that they
are actually running. With Jetty it's just a question of catching an exception
but with Tomcat it's harder (the current solution involves duplicating some
code from initialize() into start() essentially checking the lifecycle state).

Also adjusted the log levels to prevent noise at WARN level by default when
this happens (since the exception is logged and rethrown anyway).

There is still the issue of whether to fail the build in Maven or Gradle
(separate issue really).

Fixes gh-1232
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
Fix typo
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
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.