Add CPack support to provide Win32 binaries and github releases

[TcT2k]

Partly as general improvement but also specifically addressing issue #148

• Add CPack support to package binaries (as ZIPs or tar.gz for now)
  • This would also allow other types of packages later on like Windows/mac installers
• Collect package as artifacts in appveyor
• Deploy artifacts as github release like this
• Cache unicorn build for MSYS build #92

Open ToDos (some of which I need input on):

• [x] Include version number in executable
  • [x] Print during to log
  • [x] Add to SDL window title
• [x] Decide to always create a release or just for tags
• [x] Releases in same repo or different one
• [x] Release naming (filename currently uses git revision, release name uses appveyor automatic "version number")

I'll create issues for a few open things after this is merged:

• Include MSYS dependencies in package

[JayFoxRox]

Looking good! Thanks a lot for looking into it.

Here are my thoughts:

• We can add MSYS deployment at a later stage to fast-forward this change, simply because one deployed Windows build is enough (for now); gcc builds will get a lot of testing through Linux and macOS anyway. We'll also continue to run MSYS on CI. Multiple releases might even be confusing to users - this would be resolved when having a custom webfrontend.
• We should always generate a build, so we can have "nightly" build, even when we don't release a new major update.
• There should still be major updates from time to time to mark stable versions (to be included in package managers etc.) or announce completion of major features.
• We should not build PRs for security reasons. If people want cutting-edge features, they should just run their own builds at their own risk. So only the reviewed master-updates or tags should get build.
• Not sure about which repo to release on. But I think this repo is fine as it has the most appropriate name. Reasons for moving it would be stronger seperation of users/developers, but that seperation can also happen with a webfrontend on our website later.
• When there's a screenshot, we should always know which version it was from, so we should add the git revision information into the SDL window title (other projects I've worked on also do this).
• Binary filename should probably stay openswe1r, packagename name should be something like OpenSWE1R-[-dirty].zip ? Release name also something like OpenSWE1R-<git-commit> ? To be honest, it has been a couple of months (/ years?) since I've worked on deployment, so I'm not even sure what our options are.
• GNU in packagename is confusing, I'd suggest using OpenSWE1R-<git-commit>-x64-Windows-MSVC and OpenSWE1R-<git-commit>-x64-Windows-MSYS. This turns the last part into an optional variant. Linux and macOS would just be called OpenSWE1R-<git-commit>-x64-Linux and OpenSWE1R-<git-commit>-x64-macOS. You'll also notice that I split OS and architecture, because we'll eventually have other architectures probably. So we should be more explicit about it (architecture could also be moved to the end or something - I don't know).
• (Edit:) Consider naming it "openswe1r" in all lowercase (in general the filename could be all lowercase), so we can make a distinction between the "OpenSWE1R" collection of projects (such as "swe1r-tools" etc.) and the actual rewrite ("openswe1r").

(Also consider joining our gitter.im channel)

[JayFoxRox]

I just merged this as-is. I had intended to do this months ago but got distracted with other projects. By now I've lost oversight - rather than delaying this further and causing more work, I think it's better to just accept this change. If there's anything broken or horrible it can be fixed iteratively.

Thanks for this large contribution!