Replace references to 'files' throughout the code-base with 'sources'
following the rename of `FileOptions` to `SourceOptions`.

Also cleanup ResourceUtils a little

Fixes gh-209 in a general way

Fixes gh-208

Fixes gh-205

We check for existence of the sources and (as before) resolve multiple
resources on the classpath if a path is not a File. In addition supports
Spring pseudo-URL prefixes as well as normal URLs as source locations.

In addition sources can now be specified as a directory (searched
recursively by default), or a resource pattern (e.g. app/**/*.groovy).

Fixes gh-207

fixes #206

Recent changes to the repository configuration for @Grab
didn't update the tests which use the GroovyCompiler as
a standalone. Fixed that by using the
RepositoryConfigurationFactory.

This should make a difference to gh-196. It might even fix it
(depending on what snapshot the user had there).

Fixes gh-204

Fixes gh-202

Migrate JolokiaAutoConfiguration to use ConfigurationProperties instead of accessing the environment directly to obtain configuration properties

Fixes gh-198

Instead of adding active prpfiles for every one we encounter, we need to
build up a complete "default" Environment and then ask it what the active
profiles are. Implemented in ConfigFileApplicationListener.

Fixes gh-198

Previously, there were two <manifestEntries> elements in the CLI's
pom.xml. With certain versions of Maven, this appeared to cause the
first element to be ignored in favour of the second. The problem did
not occur when built locally with Maven 3.1.1, but did occur when built
by Bamboo which, I believe, uses 3.0.x

This commit combines the two <manifestEntries> into one.

The test passes locally, both in Eclipse and on the command line, but
fails on the CI server. Revert the addition of the test while I
hopefully figure out why.

This reverts commit 2e81b1d0.

The grab command downloads the dependencies of one or more Groovy
scripts to ./repository. This commit ensures that those previously
downloaded dependencies can be used by a subsequent invocation of the
run command.

The location and behaviour of the local cache is unaffected by this
change. If the dependencies in ./repository do not exist in the local
cache, Aether will "download" them from ./repository and store them in
the local cache.

Fixes #191

Previously, Aether's configuration was largely hard-coded making it
impossible to configure a mirror, provide credentials for accessing
a repository, etc.

This commit adds support for configuring Aether via Maven's
settings.xml file. The support is optional and must be enabled by
grabbing spring-boot-maven-settings in an init script. The Aether
instance that's used when running the application will then be
configured using settings.xml. The settings file is expected to be
found in ${user.home}/.m2/settings.xml.

The configuration of the following items is currently supported:

 - Offline
 - Proxies
 - Mirrors
 - Server authentication
 - Local repository location

If the support is not enabled, settings.xml does not exist, or
settings.xml does not configure certain things then sensible defaults
are applied.

When an init command is run, it may add entries to the classpath. This
commit adds a test that verifies that, if an entry that is added to
the classpath contains a CompilerAutoConfiguration file in
META-INF/services, then the CompilerAutoConfigurations declared in it
are found by subsequent ServiceLoader.load calls.

Also logs a warning about the fact that locks may not be taken when
starting a Job. JPA and Batch don't really work that well together
in general so it's probably not worth a lot of effort to work aoround
this. If anyone needs to they should create a custom JpaDialect
(and a BatchConfigurer).

Fixes gh-197

Fixes gh-195

Previous fix for handling wildcard entries in a classpath
imposed a new problem in a case where entry is a directory
with a jar files but also contains a lot of nested directories.

For example entry "./*" resulted for scanning whole disk starting
from "/". In case of default hadoop classpath, it scanned everything
under hadoop's installation. On some cases this deep scan was hidden
and was revealed by NPE's for file access exceptions.

When we want to support wildcard entries we only want to get
jar files from that directory, while boot itself have a need
to travel recursively to find classfiles from an expoded archive.

We handle this case by using recursive(true by default) flag in
ExplodedArchive and this flag is set to false in PropertiesLauncher
if we match wildcard.