New functions to get kernel thread Id + serialisable task Id

On most platforms the userspace thread type (e.g. pthread_t) and kernel
thread id are different. Normally we don't care about kernel thread Ids,
but some system tools for tracing/profiling etc report kernel ids.
For example Solaris and OSX's DTrace and Linux's perf tool report kernel
thread ids. To be able to match these up with RTS's OSThread we need a
way to get at the kernel thread, so we add a new function for to do just
that (the implementation is system-dependent).

Additionally, strictly speaking the OSThreadId type, used as task ids,
is not a serialisable representation. On unix OSThreadId is a typedef for
pthread_t, but pthread_t is not guaranteed to be a numeric type.
Indeed on some systems pthread_t is a pointer and in principle it
could be a structure type. So we add another new function to get a
serialisable representation of an OSThreadId. This is only for use
in log files. We use the function to serialise an id of a task,
with the extra feature that it works in non-threaded builds
by always returning 1.
Fix compile failure on non x86/x86-64 (#7054).
Don't re-allocate %esi on x86.

Recent changes have freed up %esi for general use on x86 when it is
not being used for R1.  However, x86 has a non-uniform register
architecture where there is no 8-bit equivalent of %esi.  The register
allocators aren't sophisticated enough to cope with this, so we have
to back off and treat %esi as non-allocatable for now.  (of course,
LLVM doesn't suffer from this problem)

One workaround would be to change the calling convention to use %rbx
for R1, however we can't change the calling convention now without
patching LLVM too.
Don't look for objdump on OS X
Track liveness of GlobalRegs in the new code generator

This gives the register allocator access to R1.., F1.., D1.. etc. for
the new code generator, and is a cheap way to eliminate all the extra
"x = R1" assignments that we get from copyIn.
Don't duplicate arbitrary CmmCalls
The final GC should be a major one

We do a final GC before shutting down the system, to clean up.
However, we were doing an ordinary GC rather than forcing a major GC,
so especially when the allocation area is large, this final GC could
be expensive.  This is really just a bug - the final GC should have
virtually nothing to do, because there is nothing live.
Parallelise clearNurseries() in the parallel GC

The clearNurseries() operation resets the free pointer in each nursery
block to the start of the block, emptying the nursery.  In the
parallel GC this was done on the main GC thread, but that's bad
because it accesses the bdescr of every nursery block, and move all
those cache lines onto the CPU of the main GC thread.  With large
nurseries, this can be especially bad.  So instead we want to clear
each nursery in its local GC thread.

Thanks to Andreas Voellmy <andreas.voellmy@gmail.com> for idenitfying
the issue.

After this change and the previous patch to make the last GC a major
one, I see these results for nofib/parallel on 8 cores:

   blackscholes          +0.0%     +0.0%     -3.7%     -3.3%     +0.3%
          coins          +0.0%     +0.0%     -5.1%     -5.0%     +0.4%
           gray          +0.0%     +0.0%     -4.5%     -2.1%     +0.8%
         mandel          +0.0%     -0.0%     -7.6%     -5.1%     -2.3%
        matmult          +0.0%     +5.5%     -2.8%     -1.9%     -5.8%
        minimax          +0.0%     +0.0%    -10.6%    -10.5%     +0.0%
          nbody          +0.0%     -4.4%     +0.0%      0.07     +0.0%
         parfib          +0.0%     +1.0%     +0.5%     +0.9%     +0.0%
        partree          +0.0%     +0.0%     -2.4%     -2.5%     +1.7%
           prsa          +0.0%     -0.2%     +1.8%     +4.2%     +0.0%
         queens          +0.0%     -0.0%     -1.8%     -1.4%     -4.8%
            ray          +0.0%     -0.6%    -18.5%    -17.8%     +0.0%
       sumeuler          +0.0%     -0.0%     -3.7%     -3.7%     +0.0%
      transclos          +0.0%     -0.0%    -25.7%    -26.6%     +0.0%
--------------------------------------------------------------------------------
            Min          +0.0%     -4.4%    -25.7%    -26.6%     -5.8%
            Max          +0.0%     +5.5%     +1.8%     +4.2%     +1.7%
 Geometric Mean          +0.0%     +0.1%     -6.3%     -6.1%     -0.7%
Comments and pretty printing
Suppress ambiguity errors if there are other solid errors to report
Tidy up validity checking of types, esp in contexts
Remove dead code
Remove dead code
More changes to kind inference for type and class declarations

These should fix #7024 and #7022, among others.

The main difficulty was that we were getting occ-name clashes
between kind and type variables in TyCons, when spat into an
interface file. The new scheme is to tidy TyCons during the
conversoin into IfaceSyn, rather than trying to generate them
pre-tidied, which was the already-unsatisfactory previous plan.

There is the usual wave of refactorig as well.
Merge branch 'master' of http://darcs.haskell.org/ghc

Conflicts:
	compiler/typecheck/TcRnDriver.lhs
Be careful not to look for Functor unnecessarily

Otherwise we try to load package 'base' when
we are compiling 'ghc-prim'.
See Note [Getting base classes]
Merge branch 'master' of http://darcs.haskell.org/ghc
Merge branch 'master' of ../HEAD
Define the task-tracking events

Based on initial patches by Mikolaj Konarski <mikolaj@well-typed.com>

These new eventlog events are to let profiling tools keep track of all
the OS threads that belong to an RTS capability at any moment in time.
In the RTS, OS threads correspond to the Task abstraction, so that is
what we track. There are events for tasks being created, migrated
between capabilities and deleted. In particular the task creation event
also records the kernel thread id which lets us match up the OS thread
with data collected by others tools (in the initial use case with
Linux's perf tool, but in principle also with DTrace).
Emit the task-tracking events

Based on initial patches by Mikolaj Konarski <mikolaj@well-typed.com>

Use the new task tracing functions traceTaskCreate/Migrate/Delete.
There are two key places. One is for worker tasks which have a
relatively simple life cycle. Worker tasks are created and deleted by
the RTS. The other case is bound tasks which are either created by the
RTS, or appear as foreign C threads making calls into the RTS. For bound
threads we do the tracing in rts_lock/unlock, which actually covers both
threads coming in from outside, and also bound threads made by the RTS.