- fix: eclipse benchmark had the wrong (old) MD5s
- fix: missing and old MD5s for Jython downloads
- fix: broken link for NSIS 3
- remove Maven memory restriction, which caused build to fail on weasel.moma
- add CI caching
- use small size when testing runnability on CI
- add ability to clone and checkout from git repo
- display warning message if build is not a release build

Improved README

Added a section on how to use callbacks.

Version bump for all 9.12 benchmarks, validated on OpenJDK 8

The problem was because Geronimo server wants to read from stdin.
GitLab runner doesn't provide stdin, so it just reads an EOF and quits.
This is why GBeans is not running.
Thus the solution is to keep stdin open for the duration of the benchmark.
Setting a time out (120 seconds) with `sleep` command seems to work.
NOTE: this value may need to be modified on slower machines.

When trying to locally test the CI problem, there was another
issue with running gitlab-runner locally.
It seems that during the deploy stage of building DayTrader,
Geronimo tries to execute `stty -icanon min 1 < /dev/tty` command.
It causes the whole thing to hang.
The reason might be that tty is not enabled in gitlab-runner.
I found a hacky
[solution ](https://gitlab.com/gitlab-org/gitlab-runner/issues/1021)
that uses the script command to emulate tty. And it seems to work.

Callback path fix

See merge request dacapo/anu-dev/dacapobench!11

If batik is built before fop, fop's lib dependency on batik
will overwrite the patched batik jar.
There was a previous commit that attempts to deal with the issue,
but it created dependency not found problem when
fop is the only one built.
This commit properly deals with the issue by renaming the
batik jar that fop depends on, thus not overwriting the patched
batik benchmark.

The path for harness in the target dacapo.jar
has been put under the harness/ prefix.
This caused incompatibility problems with previous releases.
This commit fixes this problem.

Fop carries a batik-all-1.9.jar with it, which will overwrite the batik benchmark jar
when unzipped into scratch directory, rendering the patch to batik 1.9 ineffective.
Fop benchmark doesn't seem to actually use the jar. So removing it from the list of
jars to include in fop doesn't affect running fop benchmark, and batik is now fine.