Remove workaround to overwriting jars

[hinerm]

Currently the updater puts jars in a temporary directory that is consolidated by the launcher on launching. This is primarily to work around the aggressive .jar locking by Windows.

Java 7 introduced the URLClassLoader.close method, which will free up any jars loaded by the ClassLoader for deletion/overwriting.

This will require careful consideration of ClassLoader hierarchy but will allow for a simpler launcher. It would be good to combine with compile and run work as well, as that could also involve ClassLoader restructuring.

[hinerm]

MCVE for testing this: https://gist.github.com/hinerm/5721562ade5562d8599b

[hinerm]

To test: what happens with the system classloader? (that is, confirm we understand how ImageJ 1 is able to rewrite itself..)

[hinerm]

MCVE for a jar loaded by the system class loader to overwrite itself:
https://gist.github.com/hinerm/ac02be7beacaa1a065b3

A jar with this main class is able to overwrite itself on windows.

[ctrueden]

We are switching the Fiji launcher to a new one we made called Jaunch. Jaunch does include the same logic for stashing updates in a special update folder. This is more robust than assuming your running Java program will always let go of file locks on Windows. It's fine; it works. 😄