Getdown and Install4j bundled JRE expectations on macOS confliction

This issue discusses the conflict found between getdown's bundled JRE and install4j's bundled JRE on macOS using the DMG Jalview.app bundle method in install4j. We don't want to bundle two JREs!

* In the default install4j Jalview.app bundle if install4j bundles a JRE it puts it in

Jalview.app/Contents/Resources/jre.bundle

and uses the Mac style JRE install that looks like:

jre.bundle/
└── Contents
        ├── Home/... [actual JAVA_HOME]
        ├── Info.plist
        └── MacOS
                 └── libjli.dylib -> ../Home/lib/jli/libjli.dylib

* getdown (sitting within the install4j app-bundle) by default installs a bundled JRE in

Jalview.app/Contents/Resources/app/java_vm/... [actual JAVA_HOME]

which doesn't use the Contents/Home dirs.

* install4j can be configured to look for the JRE elsewhere in the Jalview.app bundle, e.g. Jalview.app/Contents/Resources/app/java_vm. However it still insists on wanting a Mac OS style JVM bundle with Contents/Home and importantly the symbolic link Contents/MacOS/libjli.dylib. Annoyingly this has to be a symbolic link, a copy of the libjli.dylib file it is pointing at doesn't work.

I have modified getdown source to also look for a JRE bundled in java_vm/Contents/Home.
So far so good... however:

* getdown updates the java_vm using a .jar file, which cannot deal with symbolic links.

Q: Can we just put the symbolic link in once before installation and not change it in JRE updates?
A: No. I have noticed that in java12, the file the link points at MOVES from Home/lib/jli/libjli.dylib to Home/lib/libjli.dylib.

1) Since we cannot change install4j, we're going to have to use a JRE with the MacOS Contents/Home and the Contents/MacOS/libjli.dylib symbolic link.
2) Since this symbolic link might change (indications from java 12 suggest will change), the JRE unbundling should be able to replace a symbolic link.
3) We /can/ change getdown.

So, I've made some reasonable additions to getdown so that it's Application.getJavaVMResource() method will allow both .jar and .tgz file extensions in the java_location URL. If it's .tgz then getdown uses the Apache Commons Compress library to gunzip|untar the file (in fact this will now work for any resource in getdown.txt). This should allow us to use "proper" Mac OS JRE bundles.

At time of writing this compiles okay, but is untested... updates to come.