Add GHCJS support to the Simple build infrastructure

This is the whole GHCJS build system, I've tested this with GHCJS based on GHC HEAD and on 7.8.3, `cabal install`, `cabal test`, `cabal run`, Haddock, sandboxes etc all work. Apologies for the rather large amount of code in a single commit. Fortunately most of the changes are relatively straightforward:

- some of the code in `Distribution.Simple.GHC` is moved to `Distribution.Simple.GHC.Internal`, from where it can be shared between multiple similar (GHC-derived) compilers.
- In order to make the shared code work reasonably well, many of the feature / quirk dependent code paths now use `GhcImplProps` from `Distribution.Simple.GHC.Props` rather than checking version numbers (which are different between the compilers). This mostly affects the Haddock and HcPkg modules and GHC command line rendering.
- The `GHCJS` flavor is handled throughout the code and in some places the hardcoded assumption that GHC is used has been removed (Building `Setup.hs` scripts and initializing package databases for example)
- The `Distribution.Simple.GHCJS` module contains most of the GHCJS-specific build code. It's very similar to `Distribution.Simple.GHC` and pretty big. More code can be shared with the GHC flavour, but that would have required more invasive restructuring of the code, which i didn't want to do in the first version.

Note that the reported architecture of the GHCJS compiler is that of the build machine. This is done to support `native-too` mode, where all code is built for the build machine too.

The `Cabal` library is compiled to JavaScript as part of the GHCJS installation procedure (`ghcjs-boot`). Some functionality (`createPipe`) is not yet supported, so I'm just throwing an exception there on the `ghcjs_HOST_OS` platform. The limitation should be removed at some later point.
That's somewhat tricky, since `GHCJS` can produce native code when installed in `native-too` mode (which used to be the default, before native code was dropped as a requirement for Template Haskell). Whether a particular executable is then native depends on other flags (the flags that `SetupWrapper` passes would always build a JS script though).

On Windows, the produced executable would actually be native code, even if GHCJS is not `native-too`, since we don't have a general way to have executable JavaScript scripts, like `#!/the/location/of/node` on unix-like operating systems. GHCJS outputs a native wrapper program that just calls `node.js` with the produced script.

So in the end I couldn't really think of a simple general property to decide whether to skip stripping that'd cover this, so this seemed most straightforward.