Maintain classpath order in PropertiesLauncher

I think this is safe, judging by the integration tests, but I'm not
putting it in 1.2.x until we've had some feedback on it. The
integration tests actually had a bug that was masking this problem
because they were merging Properties from the whole classpath instead
of picking the first available resource (which is generally what
we do in Spring Boot applications for application.properties for
instance).

Fixes gh-3048

spring-boot-docs/src/main/asciidoc/appendix-executable-jar-format.adoc

@@ -202,7 +202,7 @@ properties (System properties, environment variables, manifest entries or
 |Key |Purpose
 
 |`loader.path`
-|Comma-separated Classpath, e.g. `lib:${HOME}/app/lib`.
+|Comma-separated Classpath, e.g. `lib,${HOME}/app/lib`. Earlier entries take precedence, just like a regular `-classpath` on the `javac` command line.
 
 |`loader.home`
 |Location of additional properties file, e.g. `file:///opt/app`
@@ -236,6 +236,7 @@ Environment variables can be capitalized with underscore separators instead of p
   the default) as long as `loader.config.location` is   not specified.
 * `loader.path` can contain directories (scanned recursively for jar and zip files),
   archive paths, or wildcard patterns (for the default JVM behavior).
+* `loader.path` (if empty) defaults to `lib` (meaning a local directory or a nested one if running from an archive). Because of this `PropertiesLauncher` behaves the same as `JarLauncher` when no additional configuration is provided.
 * Placeholder replacement is done from System and environment variables plus the
   properties file itself on all values before use.