Rename spring-boot-starter-cloud in spring-boot-dependencies

Fixes #1781
Upgrade to Spring Batch 3.0.2.RELEASE

Closes gh-1782
Merge branch '1.1.x'

Conflicts:
	spring-boot-dependencies/pom.xml
Fix a typo in error.whitelabel.enabled
Merge pull request #1763 from sdeleuze/whitelabel-typo

* whitelabel-typo:
  Fix a typo in error.whitelabel.enabled
More testing of context hierarchy creation

There actually isn't anything much we can (or should) change here. Spring always
copies PropertySources and profiles down into the child context when you set its parent.
That seems sensible. So you can add a new profile in a child context but it will always
"inherit" from its parent.

See gh-1776
Add email support

This commit adds a new starter to auto-configure a MailSender when the
necessary classes are present and when the property "spring.mail.host" is
set.

The auto-configuration also accepts any arbitrary properties that
JavaMail might need using the "spring.mail.properties" prefix.

Fixes gh-1760
Add missing close
Align new JavaMail dependencies with Spring IO Platform

Spring IO Platform already provides dependency management for JavaMail.
This commit updates Boot’s new JavaMail dependency management to align
with the Platform, thereby allowing the Platform to inherit Boot’s
dependency management instead of defining its own.
Allow multiple templateLoaderPaths to be configured for FreeMarker

Closes gh-1767
Update email addresses in pom files to use new pivotal.io domain

Closes gh-1774
Merge branch '1.1.x'
Include condition's location (class or method name) in message

Closes gh-1787
Merge branch '1.1.x'
Polish
Rework logging to prevent double initialization

Prior to this commit LoggingSystem initialization would happen multiple
times. Once to configure "quiet" logging, and again to configure correct
settings once the Application was initialized. This could cause problems
if `logging.groovy` logback files were used.

The logging system is now only initialized once (when possible) by
following these steps:

- Standard logging initialization occurs via the actual logging
  implementation used (e.g. logback will load a logback.xml file if it
  exists)
- beforeInitization() is called to prevent early log output.
  Implementations now either use a Filter or simply set the root logging
  level.
- initialize() is called with an optional log configuration file (e.g
  a custom logback.xml location) and an optional log output file (the
  default is null indicating console only output).

The initialize() method will attempt to prevent double initialization
by checking if a standard configuration file exists. Double
initialization now only occurs in the following situations:

- The user has a standard configuration file (e.g. classpath:logback.xml)
  but also specifies a logging.config property. Double initialization is
  required since the specified configuration file supersedes the default.
- The user has a standard configuration file (e.g. classpath:logback.xml)
  and specifies a logging.file property. Double initialization is
  required since the standard configuration may use a ${LOG_FILE}
  reference.

In addition this commit removes the `logging.console` option and now
assumes that logging either occurs only to console or to both the
console and a file. This restriction helps simplify the LoggingSystem
implementations. If file only logging is required a custom logback.xml
can be used.

Fixes gh-1091
See gh-1612, gh-1770
Undertow starter added

Code in separate module since Undertow uses Servlet 3.1 API
and cannot be build together with other spring-boot parts that
support Servlet 3.0 API

Java6 is supported in Undertow.