Otherwise it isn't updated properly if rts/Main.c changes

Revert this patch:
    Matthias Kilian <kili@outback.escape.de>**20090920181319
    Don't build haddock if HADDOC_DOCS = NO, and disable HADDOC_DOCS
        if GhcWithInterpreter = NO
    Haddock uses TcRnDriver.tcRnGetInfo, which is only available if
    GHCI is built. Set HADDOC_DOCS to NO if GhcWithInterpreter is NO,
    and disable the haddock build if HADDOC_DOCS = NO.

  
There are already constructors for IntPrim, FloatPrim etc,
so this makes it more uniform.
  
There's a corresponding patch for the TH library

- Implement missing functions for setting thread affinity and getting real
  number of processors.
- It is available starting from 7.1-RELEASE, which includes a native support
  for managing CPU sets.
- Add __BSD_VISIBLE, since it is required for certain types to be visible in
  addition to POSIX & C99. 

Do not use GCC pragmas for controlling visibility, because it causes
"undefined reference" errors at link-time.  The true reasons are
unknown, however FreeBSD 8.x includes GCC 4.2.1 in the base system,
which might be buggy. 

This fixes trac bug #1344

We were using it only when building the RTS, and only on certain
platforms. However, some versions of OS X need the flag, while others
don't support it, so we now test for it properly.

We modify fields a lot, so we retain the old value if they aren't forced.

We now first collect the option instructions (from the commandline,
from pragmas in source files, etc), and then later flatten them into
the list of enabled options. This will enable us to use different
standards (H98, H2010, etc) as a base upon which to apply the
instructions, when we don't know what the base will be when we start
collecting instructions.

This was discombobulated by a patch a week ago;
now fixed, quite straightforwardly.  See
Note [Default methods and instances]

It turns out that TH.Syntax is rich enough to express even GADTs,
provided we express them in equality-predicate form.  So for
example

  data T a where
     MkT1 :: a -> T [a]
     MkT2 :: T Int

will appear in TH syntax like this

  data T a = forall b. (a ~ [b]) => MkT1 b
           | (a ~ Int) => MkT2

While I was at it I also improved the reification of types,
so that we use TH.TupleT and TH.ListT when we can.

Currently, many programs compiled with GHC at -O2 and LLVM
set to -O3 will segfault (only under OSX). Until this issue
is fixed I have simply 'solved' the segfault by lowering
the max opt level for LLVM used to -O2 under OSX.

All these recent changes to OSX should mean its finally as
stable as Linux and Windows.

In GHC 6.12.x I found a rare deadlock caused by this
lock-order-reversal:

AQ cap->lock
  startWorkerTask
    newTask
      AQ sched_mutex

scheduleCheckBlackHoles
  AQ sched_mutex
   unblockOne_
    wakeupThreadOnCapabilty
      AQ cap->lock

so sched_mutex and cap->lock are taken in a different order in two
places.

This doesn't happen in the HEAD because we don't have
scheduleCheckBlackHoles, but I thought it would be prudent to make
this less likely to happen in the future by using a different mutex in
newTask.  We can clearly see that the all_tasks mutex cannot be
involved in a deadlock, becasue we never call anything else while
holding it.