Cross-Platform Building & Build Process Cleanup


## Changes

1.  All 3 platform releases can be built on Windows & Mac (and possibly linux & solaris, they're untested atm).
2.  The Mac distribution has changed from a dmg file to a zip file.
3.  All Mac build files have been merged into the master build.gradle.
4.  The build.gradle file has undergone massive revision, in an effort to make it more maintainable and understandable for new developers.
5.  All subproject build.gradle files have been altered to remove their SourceSets, and these are now declared in the master build.gradle file.
6.  All SourceSets are specified using shorthand notation.
7.  All releases now include as documentation only the GNU GPL license.txt file and our release_notes.txt (Currently just versions.md renamed).
8.  The windows installer finish screen now has a checkbox to launch anathema, a link to the anathema website, and a checkbox to open up a browser window to the markdown formatted release notes.
9.  The binary files for [launch4j] (http://launch4j.sourceforge.net/) (win, mac, linux, solaris) and [NSIS](http://nsis.sourceforge.net) (win, mac) have been checked into source control.  I had to compile the mac binaries myself, and the same will have to be done for linux/solaris developers who wish to build the NSIS windows installer.
10.  It is now possible to build the windows installer without installing NSIS on your development machine.
11.  [nsisant](http://danielreese.com/nsis-ant/) has been upgraded from 1.2 to 1.3
12.  The splash screen for mac users has been re-enabled (in fact, I'm not sure it was ever enabled for Mac users)
13.  README.md has been updated to reflect changes to build and release commands.
14.  The `gradlew clean` task now deletes the root `build` folder.
15. A new `gradlew release` task has been added to build all release artifacts


## Comments

-  1) will require some test building on linux & solaris, possibly compiling makensis for those platforms as well.
-  4) `buildZip`, `buildWin`, `buildMac` are now the primary tasks for compiling for those platforms.  They compile the relevant code, `buildWin` will generate the launcher `anathema.exe`, and `buildMac` will generate the `Anathema.app` application bundle folder (this will work as an executable application bundle if built on a unix based system)
-  4) `releaseZip`, `releaseWin`, `releaseMac` are now the primary tasks for generating release artifacts.  They depend on their build counterparts, and `releaseWin` will generate the installer executable, while `releaseMac` will generate a zip file containing the application bundle (the extracted application will work no matter what platform it was built on)
-  4) `buildMac` when run on a windows system is unable to set execute permissions for the java stub (as this is not possible on FAT/NTFS), but `releaseMac` sets execute permissions inside the zip file, so the extracted contents work no matter where they were built.
-  5) I'm ambivalent about this change.  I tried it on a whim, in an effort to clean up the SourceSet craziness (it was very hard to figure out what the SourceSets were for any particular project, because you had to refer to both that project's build.gradle file, as well as the master build.gradle file, where it was appending to the SourceSets depending on the name of the project.)
-  5) I found that everything builds fine if you specify the full src/test/resources SourceSets for *all* sub-projects.  This greatly simplifies things, and cleans up a lot of duplicated code.
-  5) I was a little worried about a performance impact of specifying the SourceSets for projects that didn't need them, so I ran a series of timed trials before and after the change.  I found the speed differences were nonexistent.  I would like to test this on a HDD rather than on a SSD, and make sure this is the case for all developers.
-  7) Honestly, the readme.txt and FAQ.txt are very dated, and the information could be easily cleaned up and put on the website, so I had no qualms about removing them from releases.  In addition, Custom Charms.txt would be much better served by being a webpage, where we can illustrate (with pictures and links to XML validation tools) how to use it.  I'm still on the fence about including release_notes.txt (versions.md), as we can easily include a link to the markdown formatted release notes on the web instead.
- I found an alternative to using the NSIS [AccessControl](http://nsis.sourceforge.net/AccessControl_plug-in) plugin: `Exec 'cacls.exe "$INSTDIR\repository" /t /e /p USERS:F'`, but I was hesitant to switch until it had been tested thoroughly on multiple windows installs.

## Things yet to do
- The wiki needs to be updated to reflect the new release process (only github contributors can update this).  Should look something like this:
    1.  Change the version numbers and version name in [gradle.properties](https://github.com/anathema/anathema/blob/master/gradle.properties)
    2.  Run `gradlew clean release` to do a clean build of all files and generate release artifacts
    3.  Post all 3 releases to sourceforge in a new version folder (example: Anathema 4.2.0 Whitewall) [Requires release manger status on sourceforge.net/projects/anathema]
    4.  Tag all releases properly on sourceforge (descriptions and OS checkboxes) [Requires release manager status on sourceforge.net/projects/anathema]
    5.  Run `git tag -a vA.b.c` to tag the version on github [Requires contributor status on github.com/anathema]
    6.  Run `git push --tags` to publish the tag to the main repository [Requires contributor status on github.com/anathema]
- The website needs to be updated to add in the content that used to exist in readme.txt, Custom Charms.txt, and FAQ.txt


## Future enhancements

- New task to tag the current commit on github as a new release
- New task to upload distribution artifacts to sourceforge
- New task to handle the complete tag->build->release->upload process.