Rather than using the autoconf built-in stuff and mangling it, we
now just ask the bootstrapping compiler what platform we are on.

When doing a port of GHC, you need to specify the platform you are
porting to.

The minimum version of GHC required is now 6.8.

Now that the clean rules don't require libraries/*/ghc.mk, we don't
have to build them on demand.  And having them built on demand
introduced a failure mode (where some libraries have ghc.mk and some
don't).

Overwriting means we lose the -m64 on OS X 64.

Without -shared, the default target is a binary and in that case
it makes sense for --make to not try and link a binary when there
is no Main module. But for a shared library the user already has
to specify -shared and there's no reason a shared lib should
contain any Main module or main function.

It tried to do this already, but the make variable name was wrong.

This is now the same as the old default. Currently we cannot embed
rpaths because they would point to the build tree. We should embed
rpaths relative to the $ORIGIN in future.

Previously it only did it for binaries. This was presumably on the
theory that the binary could specify the rpath for all the libs.
However when it is the shared lib that is the final product (ie to
link into a bigger project) then we need the rpaths for the shared
lib to be self-contianed.

The previous default was Deployable though it was being
overridden to Wrapper in the ghc shell script wrapper.

It's still possible to override it, just use -optl-Wl,-soname, eg:
ghc -shared -dynamic foo.o -o libfoo.so -optl-Wl,-soname,libbar.so

Previously the object code for the C main function lived in the rts
lib, however this is a problem when the rts is built as a shared lib.
With Windows DLLs it always causes problems while on ELF systems it's a
problem when the user decides to use their own C main function rather
than a Haskell Main.main. So instead we now put main in it's own tiny
little static lib libHSrtsmain.a which we install next to the rts libs.
Whenever ghc links a program (without -no-hs-main) then it also links
in -lHSrtsmain. For consistency we always do it this way now rather
than trying to do it differently for static vs shared libraries.

We now do it for all ways and for all platforms. This was a Windows-only
version that only kept a separate Main.dyn_o for the dynamic linking case.
It had to do that because Windows DLLs are stricter about unresolved symbols
where as for ELF platforms we only run into the problem when we're not using
a Haskell main function.