Bash expressions do not fail 'single entry' check

Previously, if the value of a JAVA_OPTS was a bash expression (like in
the AppDynamics Framework), it would run afoul of the enforcement that
values in JAVA_OPTS must be a 'single entry'.  It would, however, only
cause a problem if a custom JAVA_OPT was specified as well (via the
java_opts.yml file). This change updates the detection logic for the
'single entry' so that it makes an exception for bash expressions and
ensures that the check is only run when Play applications are being
pushed.

[#67900270]
Merge 67900270-expression-in-java-opt to master

[Completes #67900270]
Update Anchor Links

Previously GitHub used capitalization reflecting the text for anchor links, such as:

 ../README.md#Configuration-and-Extension

This recently changed to all lower case, e.g.

 ../README.md#configuration-and-extension

While the links still went to the right page they did not go to the anchor. This change
updates the affected links so they work properly.

[#67911942]
SVG Badge Update

This change updates the badges in this project to use SVG.
Update reference to running a local CF. 

The Vagrant CF installer that was previously referenced in the docs is not being actively maintained. This change refers the reader to a CF docs page that describes the best options for running CF locally.
Use Yard (see ...) syntax

Based on the results of
https://github.com/lsegal/yard/issues/720#issuecomment-38344444 the
Yard (see ...) syntax suits our needs.  This change updates all of our
docs to remove the macros and instead use that syntax.

[#68083978]
Merge 68083978-yard-see-syntax to master

[Completes #68083978]
Resolve JRE version late

Previously when detect() was called on the buildpack, it would resolve
a version of the JRE, regardless of whether the application was a Java
application or not.  This meant that any network connectivity problems
that might be highlighted by the Java buildpack would show in non-Java
projects.

An ideal solution to this would be to change the implementation of the
VersionedDependcyComponent such that version and uri resolution
happened as part of detect, but this would break compatibility for
many 3rd-party components. Instead, that resolution is moved to
detect, *but only for OpenJDK- like JREs*.  This leads to the
replication of some of the initialization code, but this is considered
a less-bad solution than breaking compatibility.

The end result is that the version and uri of
VersionedDependencyComponents will happen at initialization time, and
be avoided by inspections of the filesystem.  The JRE will not resolve
as part of initialization, but rather at detect time.

[#67329858]
Merge 67329858-delay-version-resolution to master

[Completes #67329858]
Non-webapp Spring Insight Analyzer

Previously Spring Insight required a separate web application (the
analyzer), installed as a peer to a user's primary application, in
order to function.  This meant that Spring Insight didn't conform to
the Cloud Foundry expectation that only a single application run in a
container.

This change integrates the next generation of the Spring Insight
analyzer which is implemented as a Java Agent.  It removes the
addition of the analyzer web application, and also updates the weaver
from a generic vFabric weaver to a Cloud Foundry specific weaver.

This changes leaves outstanding the possibility that it will be used
with Tomcat 8.  In the case that a Spring Insight service is bound to
an application running in Tomcat 8, it will cause the application to
fail during startup.  This issue will be addressed in a later commit.

[resolves #42]
Merge branch 'brendanbenson-insight_agent_ng2'
Add front-page link to ModularComponent docs

Previously, the detailed ModularComponent docs were not linked from
the front page.  This change adds that link.

[#67852362]
Merge 67852362-modular-component-docs to master

[Completes #67852362]
Clarify that configuration files reside in the buildpack fork

... and not in the application which some people assumed.
Copy to staging location

This is the first step in an effort to create a way to build offline-
only buildpacks.  This first step creates the Rake tasks required to
copy important files from their source locations to a staging area.

[#67851786]
Create offline TAR file

This is the second step of the effort to create offline buildpacks.
This change creates a TAR file from the staged files.

[#67852576]
Download latest dependencies

This is the third step in an effort to create a way to build offline-
only buildpacks.  This change uses the buildpack's DownloadCache and
VersionResolver to populate a cache in the staging area.  This cache
contains the latest version (as identified by the configuration) of
all of the dependencies that might be used by the buildpack at
runtime.

As this logic was so complex, this and the other offline build tasks
were broken out into their own Task classes.

[#67851722]
Disable remote downloads

This is the fourth step in creating an offline buildpack.  In this
change, the config/cache.yml file is modified to explicitly disable
remote downloads.

[#67851760]
Remove GlobalCache

This is the fifth step in creating offline buildpacks.  This change
removes the GlobalCache as it will now, never be used.

[#67852314]
Look to buildpack local cache

This is the sixth step in creating an offline buildpack.  This change
causes the ApplicationCache to look at a local location
(resources/cache) for resources when it cannot download them.

This simple requirement led to extensive changes to the DownloadCache
implementation.  The changes mostly had to do with removing code that
causes filesystem locking for cached resources.  Since the cache can
no longer be shared between processes (there is no global cache) there
was no need for the added complexity of the filesystem locking.  In
addition, the behavior around detecting when the network was
unavailable was overly complex.  This change eliminates all excess
calls to determine connectivity, instead using the needed calls to
determine it.

[#67852466]