Update OpenJDK documentation

This change update the OpenJDK documentation to reflect that there are
now three platorms and therefore are three listings to inspect for
versions.

[#57290246]
Merge 57290246-docs to master

[Completes #57290246]
Groovy files in directories

Previously, both the Groovy and Spring Boot CLI containers would only
work with Groovy files located in the application's root directory.
This change makes it so that all groovy files, regardless of their
directory will be found and used.

[#54517818]
Merge 54517818-deep-groovy to master

[Completes #54517818]
Polishing

The previous commit added some unwanted output to the test run.  This
removes it.

[#54517818]
Merge 54517818-polishing to master

[Completes #54517818]
fsync file writes

This change ensures that all file writes are fsync'd.  This is in an
attempt to address some issues we're seeing with corrupted files
shortly after they are written.

[#58149152]
Merge 58149152-fsync to master

[Completes #58149152]
Fail if system calls are non-zero

Previously, if a system call such as 'tar xf ...' failed, the
buildpack continued on as if everything had gone fine.  This was due
to the use of the 'system' call without ever checking that the return
value was 'true'.  This change creates a 'shell' call that works
similarly to the system call except that it checks the exit code of
every call and prints stdout and stderr and then fails if the exit
code is non-zero.

[#58149490]
Merge 58149490-fail-non-zero to master

[Completes #58149490]
Correct documentation.

[#58060090]
Implement memory ranges

To accommodate memory ranges, the weight balancing algorithm is
completely overhauled.

Each way in which a memory size may be specified is equivalent to a
range. Omitting a memory size is equivalent to specifying the range
`0..`. Specifying a single value is equivalent to specifying the
corresponding degenerate range.

In the four dimensional space of memory types (heap, permgen/maxspace,
stack, and native), the Cartesian product of memory ranges is a (four
dimensional) box B, all of whose edges start at a non-negative memory
size but may extend to plus infinity in any dimension if the
corresponding range is unbounded.

The total available memory ($MEMORY_LIMIT) defines a hyperplane T in
which each point has memory size coordinates which sum to the total
available memory. T separates the whole space into two half spaces.
The half space containing the origin consists of points which consume
less than the total available memory. The other half space consists of
points which consume more than the available memory.

The memory weightings describe a line W which intersects T at a single
point D (for default), which is the Cartesian product of the default
memory sizes (in the absence of any memory ranges).

In non-error cases, T intersects B in a "hypersegment" S of points
which lie within all the memory ranges and have total memory equal to
the total available memory. Note that S is convex.

The weight balancing algorithm aims to find the closest point of S to
the point D. If D lies within S, then the closest point is D itself.
If D lies outside S, then since S is convex, there is a unique point
in S which is closest to D.

The weight balancing algorithm works as follows. It first sets a
search point x to the point D. If x lies within S, the algorithm
terminates. If x lies outside S, the algorithm determines in which
dimensions x lies outside S. x is moved by constraining x to B in
those dimensions. This effectively drops a perpendicular onto B in
those dimensions. These dimensions of x are now fixed for the
remainder of the algorithm and the corresponding memory sizes are
deemed to have been allocated. If there are no remaining dimensions,
the algorithm terminates. Otherwise, the remaining dimensions of x are
recalculated by balancing the remaining memory among the remaining
dimensions. x now either lies within S in those dimensions or it does
not, in which case the above steps are repeated.

It remains to be proved that this algorithm always determines the
unique point in S which is closest to D.

Native memory is allowed to have an upper bound. Even though this
isn't particularly useful, there is no need to prohibit it and this
simplifies the documentation.

Stack size handling is improved. If a range of stack sizes is
specified and the floor of the range is non-zero, the floor is used as
the default stack size. Otherwise, the JVM default stack size is used.
Also, the number of threads, determined from the weighted proportion
of total available memory for the stack divided by the default stack
size, is rounded and, if necessary, adjusted upwards to one to behave
better in edge cases. Working in terms of a speculative number of
threads is not ideal, but it does allow stack ranges and sizes to be
converted back and forth between individual stack size and total stack
memory.

Memory weightings are generalised so that they need no longer add up
to 1.

The MemorySize type is extended to cope with a zero memory size with
no unit.

Set max permgen range based on default max permgen size. This will
improve permgen for applications with less than 640M of total memory.
Note that such applications will get less heap and a smaller stack
than would be the case without the permgen range.

[#58060090]
Merge 58060090-memory-ranges to master

[Completes #58060090]
Refactoring to reduce complexity
Dependency Updates

This change updates the dependencies of the project.  It includes code
changes required by a newer version of rubocop.

[#58800698]
Mavericks support

This change adds support for OS X 10.9 Mavericks to the buildpack.
There are no significant changes other than using the mountionlion
platform for both 10.8 and 10.9.

[#58800698]
Merge 58800698-mavericks to master

[Completes #58800698]
Prevent Tomcat container from detecting Java main applications

Implement the more general improvement of diagnosing JRE and container
cardinality issues on compile and release

Detect checks that there is precisely one JRE and one container that
are offering to run the application and fails otherwise. Compile and
release were only checking that there was at most one container.

Check on compile and release that there is precisely one JRE and one
container that are offering to run the application and fail otherwise.

Diagnostics should use container & JRE names. Previously the detect
diagnostics included the container or JRE detect tags rather than the
container or JREs themselves. This gave rise to diagnostics such as:

Application can be run by more than one container: java-main,
tomcat-7.0.42, tomcat-buildpack-support-1.1.1

which was misleading since tomcat-buildpack-support-1.1.1 is not a
container.

Change the diagnostics to use container and JRE names. For example,
the above diagnostic then becomes:

Application can be run by more than one container: ["Java Main",
"Tomcat"]

Given this general improvement, factor out Java main class location
utility and use this utility from the Tomcat and Main containers.

[#57611752]
Merge 57611752-tomcat-avoid-main-class to master

[Completes #57611752]
Factor out duplicated code

[#57611752]