CPack packaging instructions

This PR tries to setup working install and packaging rules.

I've priorized this over splitting the repositories in a sane way; on that road, I found a way to accomplish the differences in using one of our libraries and building it on its own. Though, I did not yet enforce good behaviour for the stand-alone build scenario.

| Qt | Action | Mac | Linux | Win64 | Win32 |
|----|--------|-----|-------|-------|-------|
| 4 | build | :+1: | :+1: | :+1: | :question: |
| 4 | make install | :+1: | :+1: | :+1: | :question: |
| 4 | cpack | :+1: | :question: | :+1: :-1: | :question: |
| 5 | build | :question: | :question: | :question: | :question: |
| 5 | make install | :question: | :question: | :question: | :question: |
| 5 | cpack | :question: | :question: | :question: | :question: |

The `macpack` branch of all submodules is required (There's just a one line change in each).

Each OS has now an overall block of cmake code, where such one is required. Actually, I didn't find may places where Mac OS X, general Linux and Windows share a single bit of semantics. This is driving me crazy; and I already got the feeling that what makes this code works at all is truely witchcraft.

Also, I tried to mimic the installed-state in the build directory as much as possible. I guess nobody wants to develop something and then figure out: Oh, the installed software uses so much different file system layout that nothing is working anymore...

As a consequence, this means: We're building frameworks and an app bundle and put it _workingly_ together already at build time. The result is an app-bundle that (unlike the installed one) only lacks external dependencies, but is still able to work on its own.

This - more or less - broke all other build systems. At the end of the day, this PR is a rewrite of quite everything in mgv related to installation or build-tree layout.

Furthermore, I figured out, that every change requires to re-test everything: 2 tool sets * 3 Operating Systems * 2 CPU-Archs = 12 * 10 minutes for compiling, installing and manual execution. So in the end, I hope this PR will lay a foundation that makes all of this more easy.

There are some issues still:
-	__Qt 5__
	I've not tested any of this against Qt5 yet.

-	__32 bit builds on Mac OS X, Linux and Windows__
	In general, I'm trying to avoid those as much as possible. Compiling Qt4 + 5 on 3 operating systems will take a while and I'm pushing this back until I know at least that the 64 bit versions work.

-	__libgit2__
	This one is really bothering me.
	On __Mac OS X__, the public includes and library are installed as public interface into the bundle. Looks weird. Also it's not a framework - as a result, it needs to be fixed up before being at the correct location in the bundle (We can't tell the libgit2.git submodule what to put into the CMakeLists.txt file, thus not alter the build position). This isn't stopping a "just" compiled MGV from running, though.
	On __Linux__, when installing, I put all private things, well, "private". That's not true for the headers, pkgconfig files et al comming from libgit2. Those are boldly installed into $PREFIX/include. This would very much interfer with a system-installed libgit2. Not nice either.
	But as there is no published and readily available libgit2 version on any linux distribution, we still have to bundle it into libGitWrap, probably for at least one or two years.
	On __Windows__ everything seems more smooth. Nothing interfers with something else - as there will probably never be a windows-system-libgit2. However, the installed headers and .lib files are annoying.
	Another __Windows__ issue is, that `fixup_bundle` doesn't find libgit2.dll correctly. I'm not yet sure what this is related to, but I think it's because I can't add the directory where libgit2 is built to the `INSTALL( CODE ... )`-Section that deals with `fixup_bundle`. But I cannot redirect the libgit2-build location unless I either rework the complete build system once again or tweak libgit2's root `CMakeLists.txt` file.

-	__fixup_bundle__
	Due to no available manifests (and in fact license restrictions from Microsoft), works only with release builds. Not a big deal (who wants to distribute debug packages anyway) - but it's worth mentioning. This is a problem, because it required me to skip the inclusion of debug plugins to qt. This should have been done anyway, but the debug-suffix on windows is different from the one used by Qt in Mac OS X.
	Luckily on Mac OS X, the right libraries are picked up automatically and the debug ones are ommited.
	On linux, it says that no fixup is required. Well, this is some kind of joke, probably. The truth is: Via the target property INSTALL_RPATH everything that would later on need to be fixed up has to be corrected in advance. This is another reason for wanting to setup the build-tree as much compatible to the install-tree.

-	__cmake itself__
	During the install phase, cmake executes the macros inserted via `INSTALL( CODE ... )` _before_ it dives into subdirectories. This is bad, because half of the installation instructions had to be moved out of the root CMakeLists.txt and cannot be put there (Even after my desired build-system splits are done). The other half has been moved into src/Main. That's the only other place where the final executable target should have been defined.

-	__Qt on Mac__
	I have a self-built Qt4 and one built from MacPorts. Compiling mgv against either of them results in CPack adding the system-libraries libcrypto, libz, libssl into the bundle. I'm totally unsure if this is neccessary (And actually think there's legel issues with distributing binary crypto software).
	
-	__Linux__
	And another issue is, that I don't use any binary distributions of linux. I have no way to test `RPM` or `APT` packages at all.
	Think this will require me to setup a few virtual machines.

And when we're at it: Do we care to support any of FreeBSD / NetBSD / OpenBSD / Solaris?
Will we ever require MGV to run on Android and/or iOS? This boils more or less down to: How relevant will those systems get on boxes with real screens and conventional input methods? I'm really looking forward to the days when I will be able to review a pull request using the front panel of my vaccum cleaner...