Build Cleanup - Using static classpaths rather than dynamic ones.

### Why I'm trying this

I've never been fully convinced that Anathema's dynamic classpath scheme using reflection was the way to go.  I figured I'd try to do it "normally", and see what you thought of it.

There's still room for improvement, but I wanted you to see the general direction of my thoughts before I went any farther.

### Build Cleanup

I started by getting rid of all the reflection code we use to build the classpath.  This included deleting all of the files in `:Anathema`.  I then took `:Platform_Swing/Anathema.java`, moved it to `:Anathema`, and gave it a static main method.  This is now the main class of Anathema (which incidentally fixes the menu title issue in #348).  I made `:Anathema` depend upon `:Platform_Swing` (it has to now).

`:Anathema/build.gradle` now uses gradle's runtime configurations to build a classpath, which is then put into the manifest.mf file for `:Anathema:jar`.  This replaces the old reflection code used to build the classpath dynamically.  Note that it is impossible to simply say *include all jar files from this folder* in a manifest file; You must explicitly denote each file.

I also threw in my version of the `copyAllDependencies` code while I was mucking around in here.  It seems to work well, but @UrsKR's  version worked equally well. (See my email comments on picking one over the other).

### JavaFX Exclusions

With Java 8 and newer, JavaFX classes (`jfxrt.jar`) will be on the default runtime classpath.  With Java 1.7.0_02 and higher, `jfxrt.jar` is included as part of the JRE, but you have to manually specify this file on the java runtime classpath.

Currently Anathema bundles this jar inside the JRE for Win/Mac, and we explicitly exclude it being included as part of our runtime dependencies to avoid duplication.

I ran into a minor snag with this method and the new classpaths:  There is no way to reference JAVA_HOME inside a manifest file, so you're unable to add `jfxrtr.jar` to the classpath.  

This called my attention to an edge case. While we can enforce a minimum JRE version of 1.7 for people running the Zip distribution, we can't enforce 1.7.0_21.  Since JavaFX was only included on 1.7.0_06 and newer, its possible for users with older Java 7 installs to attempt to run Anathema through the jar file, and it will fail because there is no `jfxrt.jar` on their system.

The new JavaFX bundling tasks should alleviate this, but until we switch over to it, we need a workaround.  I decided on removing our exclusions for `jfxrt.jar` from our dependencies;  I compensate by adding the same exclusion to our bundled JREs.  Thus we're still only shipping one copy of this jar, its location has just moved.

### Possible problems

I didn't see any immediate issues with our update system, but you'd know better than I would.  Because the classpath is now stored in the manifest file of `:Anathema/Anathema.jar`, if any new jar files get added to the project, then this jar file needs to be regenerated and pushed out with the update.  This should happen automatically, as the `Anathema.jar` file should be regenerated every time the classpath changes.

### Final Thoughts

Everything seems to be running just as it was before.  I didn't run any benchmarks, but I suspect Anathema will launch slightly faster now, due to the lack of dynamic classpath code.

Anyways, let me know what your thoughts are on using this approach.