Normally the out-of-heap check is performed post-GC, but there are
cases where we can detect earlier that we definitely have exhausted
the heap size limit.

This is Wolfgang Thaller's patch sent to cvs-ghc recently, with extra
commentary by me.  It turns out that this patch is not just a cleanup,
it is also necessary for GHCi to work on x86_64 with shared libraries,
because previously lookupSymbol() was creating jump-table entries for
all symbols looked up that resolved outside 2Gb, whereas Wolfgang's
version only generates jump-table entries for 32-bit symbol references
in object code that we load.

The hs_hpc_module() prototype in RtsExternal.h didn't match its usage:
we were passing StgWord-sized parameters but the prototype used C
ints.  I think it accidentally worked because we only ever passed
constants that got promoted.  The constants unfortunately were
sometimes negative, which caused the C compiler to emit warnings.

I suspect PprC.pprHexVal may be wrong to emit negative constants in
the generated C, but I'm not completely sure.  Anyway, it's easy to
fix this in CgHpc, which is what I've done.

We used to zonk quantified type variables to regular TyVars.  However, this
leads to problems.  Consider this program from the regression test suite:

  eval :: Int -> String -> String -> String
  eval 0 root actual = evalRHS 0 root actual

  evalRHS :: Int -> a
  evalRHS 0 root actual = eval 0 root actual

It leads to the deferral of an equality

  (String -> String -> String) ~ a

which is propagated up to the toplevel (see TcSimplify.tcSimplifyInferCheck).
In the meantime `a' is zonked and quantified to form `evalRHS's signature.
This has the *side effect* of also zonking the `a' in the deferred equality
(which at this point is being handed around wrapped in an implication
constraint).

Finally, the equality (with the zonked `a') will be handed back to the
simplifier by TcRnDriver.tcRnSrcDecls calling TcSimplify.tcSimplifyTop.
If we zonk `a' with a regular type variable, we will have this regular type
variable now floating around in the simplifier, which in many places assumes to
only see proper TcTyVars.

We can avoid this problem by zonking with a skolem.  The skolem is rigid
(which we requirefor a quantified variable), but is still a TcTyVar that the
simplifier knows how to deal with.

MERGE TO STABLE

This means that it'll work with all the packages that specify a cabal-version

Fixes some gratuitous warnings when compiling via C with -fhpc

I misread the code, now added a comment to explain why it isn't necessary

For some reason the C-- version of recordMutable wasn't verifying that
the object was in an old generation before attempting to add it to the
mutable list, and this broke maessen_hashtab.  This version of
recordMutable is only used in unsafeThaw#.

These changes were apparently lost during "massive changes to add a
'zipper' representation of C-"

MERGE TO STABLE

* A bug reported by Andrew Appleyard revealed that subFunTys did take
  neither type families nor equalities into account.  In a fairly obscure
  case there was also a coercion ignored.

Also common-up some duplicate bits in the platform-specific code