Fix properties binding to SpringApplication

Fix ConfigFileApplicationListener to correctly bind
`application.properties` to SpringApplication. Binding in RC2 failed
due to the fact that `ConfigurationPropertySources` did not extend
`EnumerablePropertySource`.

Fixes gh-346
Fallback to JVM URL handler on exception

Update the executable JAR `Handler` to fallback to the JVM handler if
the jar cannot be opened. This prevents exceptions when trying to
open URLs in the form "jar:jndi:/localhost...".

Fixes gh-347
Release version 1.0.0.RC3
Next development version
Fixup next iteration commit
Update READMEs to 1.0.0.RC3
Add some test cases and comments

In response to gh-352
Prevent EmptyStackException in case no stack of prompts is empty
Add some tests for profile behaviour

Ordering: profiles are applied in order (from the active profiles
list in the Environment), with the last one winning as far as
property values goes. This *does* mean that a profile activated
inside application.yml is applied last and hence takes precedence.
It's debatable whether that is the right semantics, but that's
what it is for now.

Re gh-342: a profile added via SpringApplication also takes
precedence over one added on the command line. Also debatable
but at least it's predictable.

Naming: a profile adds "#<profile>" to the end of a property source
name (no more, no less)
Dependency version upgrades

 - spring-integration-core 3.0.1.RELEASE (closes #360)
 - Logback 1.1.1 (closes #361)
 - maven-settings-builder 3.1.1 (closes #359)
 - maven-aether-provider 3.1.1 (closes #356)
 - jopt-simple 4.6 (closes #357)
 - SLF4J 1.7.6 (closes #318)
Add test case for profile ordering

The command line profile (or equivalently System property) is
not winning right now. Arguably that should be fixed. (Thinking...)

Relevant to gh-342
Straighten out profile ordering semantics

Here's what I think works best:

* Any profile in the Environment before application.yml
is processed takes precedence (i.e. it will be last in the
list of active profiles in the live app)

* Any profile in the Environment before SpringApplication
starts takes precedence (so any added on the command line or
with System properties come after ones added using
the SpringApplication API)

* The order of profiles in application.yml is irrelevant -
profiles are applied in the order they come out of
Environment.getActiveProfiles()

Fixes gh-342
Consider FactoryBean classes in OnBeanCondition

Update OnBeanCondition to attempt to consider FactoryBean classes
for bean type matches. To ensure early instantiation does not occur, the
object type from the FactoryBean is deduced by resolving generics on the
declaration.

Fixes gh-355
Be defensive about Spring Security dependencies

In particular don't assume that Spring Security Web is on the
classpath, just because Spring Security Core is.

Fixes gh-363
Add support for Spring Loaded in Maven and Gradle

Requires Loaded 1.1.5 (or better).

For Maven you can just add springloaded to the dependencies of the
spring-boot plugin (and also set MAVEN_OPTS=-noverify).

For Gradle add springloaded to the build dependencies (-noverify
can be added by the plugin).

In both cases there is also support for adding an arbitrary java agent
via configuration. Samples are provided in
spring-boot-sample-[simple,web-ui].

The ApplicationPlugin is only added if there is no JavaExec task
already present, and additionally it computes its own man class if
none is provided. So "gradle run" and "gradle bootRun" look
superficially similar, but "bootRun" has extra options, including
the agent and Loaded support.

Fixes gh-251, gh-183
Add snakeyaml to spring-boot-starter

Fixes gh-366
Update YAML refs in docs
Investigated JSP support

Summary: Tomcat works with WARs. Jetty doesn't work.

See gh-367
Revert change that breaks tests in werid way
Add JettyServerCustomizer for Jetty container customization

E.g. can be used to add SSL support to a Jetty container, similarly
to a TomcatConnectorCustomizer.

Fixes gh-345