Per-thread allocation counters and limits

This tracks the amount of memory allocation by each thread in a
counter stored in the TSO.  Optionally, when the counter drops below
zero (it counts down), the thread can be sent an asynchronous
exception: AllocationLimitExceeded.  When this happens, given a small
additional limit so that it can handle the exception.  See
documentation in GHC.Conc for more details.

Allocation limits are similar to timeouts, but

  - timeouts use real time, not CPU time.  Allocation limits do not
    count anything while the thread is blocked or in foreign code.

  - timeouts don't re-trigger if the thread catches the exception,
    allocation limits do.

  - timeouts can catch non-allocating loops, if you use
    -fno-omit-yields.  This doesn't work for allocation limits.

I couldn't measure any impact on benchmarks with these changes, even
for nofib/smp.
Update Haddock submodule ref. Fixes `cabal test'.
Remove external core

Signed-off-by: Austin Seipp <austin@well-typed.com>
fix rts exported symbols base_GHCziIOziException_allocationLimitExceeded_closure

Commit  b0534f78a73f972e279eed4447a5687bd6a8308e added new exported rts symbols,
but slightly misspelled them.

Observer on first compiled program:
> Linking dist/build/haskell-updater/haskell-updater ...
> /usr/lib64/ghc-7.9.20140503/rts-1.0/libHSrts.a(Schedule.o): In function `scheduleWaitThread':
> (.text+0xc4c): undefined reference to `base_GHCziIOziException_allocationLimitExceeded_closure'
> /usr/lib64/ghc-7.9.20140503/rts-1.0/libHSrts.a(RtsStartup.o): In function `hs_init_ghc':
> (.text+0x2fa): undefined reference to `base_GHCziIOziException_allocationLimitExceeded_closure'
> collect2: error: ld returned 1 exit status

CC: Simon Marlow <marlowsd@gmail.com>
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Update comment now that we have per-gen weak pointer lists.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
New deriveConstants: Sensitive to Profiling

  * Constants are Derived twice
    - Once with PROFILING on
    - Once with PROFILING off
    The old way was just to derive constants with PROFILING on. Then do
    recalculations in the actual compiler code to work out what the constants would
    be with PROFILING off.

  * Simplified how offsets are dealt with
    - Removed the distinction between struct and closure offsets
    - Now you just specify any of the following
      + The offset, for which target(s)
      + The rep,    for which target(s)
      + The macro,  for which target(s)
      + More unusual cases, like gcptr reps, and payload macros
New deriveConstants: lOAD_* macro & sensitive to TABLES_NEXT_TO_CODE

* lOAD_* macro

  - deriveConstants has always generated macros for *.cmm
    files. e.g. StgTSO_flags(ptr) which loads the address (ptr +
    OFFSET_StgTSO_flags).

  - deriveConstants now generates macros for *.hs files
    too. e.g. lOAD_StgTSO_flags dflags ptr loads the address (ptr +
    oFFSET_StgTSO_flags.

  - As a result of this. I have been able to delete a load of
    handwritten field getters in the code generator.

* deriveConstants is now sensitive to TABLES_NEXT_TO_CODE

  - deriveConstants now uses the C pre processor to test #ifdef
    TABLES_NEXT_TO_CODE

  - This is useful because deriveConstants can now derive offsets into
    the StgInfoTable and StgFunInfoTable structs, which are different
    depending on weather or not TABLES_NEXT_TO_CODE is defined.

  - Handwritten Cmm files used to get offsets for info table related
    things from from CmmParse.y. CmmParse.y got the values from
    handwritten haskell functions containing 'magic numbers'.

  - Now handwritten Cmm files get offsets for info table related things
    from DerivedConstants.h directly. Specifically

    + %ENTRY_CODE             is now StgInfoTable_entry
    + %INFO_PTR and GET_INFO are now StgClosure_info
    + %STD_INFO               is no longer needed
    + %FUN_INFO               is no longer needed
    + %GET_STD_INFO           is no longer needed
    + %GET_FUN_INFO           is no longer needed
    + %GET_ENTRY              is now StgInfoTable_entry(StgClosure_info(p))
    + %INFO_TYPE              is now StgInfoTable_type
    + %INFO_PTRS              is now StgInfoTable_ptrs
    + %INFO_NPTRS             is now StgInfoTable_nptrs
New deriveConstants: Automatically generate empty PlatformConstants

Problem:
Whenever a field was added to DeriveConstants.hs,
the same field needed to be added to utils/haddock/Helper.hs.

Fix:
DeriveConstants.hs now automatically generates 'emptyPlatformConstants'
which is used by utils/haddock/Helper.hs.
Fix validate warnings