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.
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.
Have a go at fixing the heap info DTrace build failue on OSX

This patch will need to be tested by someone on OSX.

Fixed a couple wrong names:
  CapsetID vs EventCapsetID
  gc__sync vs gc__global__sync
Merge remote branch 'mikolaj/dcoutts'
Merge branch 'master' of darcs.haskell.org:/srv/darcs//ghc
Fix typo
Add some casts to fix warnings
Whitespace only in Unique
Add a missing semi-colon
Whitespace only in RnEnv
Fix a CPP typo
Implement FastBytes, and use it for MachStr

This is a first step on the way to refactoring the FastString type.

FastBytes currently has no unique, mainly because there isn't currently
a nice way to produce them in Binary.

Also, we don't currently do the "Dictionary" thing with FastBytes in
Binary. I'm not sure whether this is important.

We can change both decisions later, but in the meantime this gets the
refactoring underway.
HsStringPrim now contains FastBytes, not FastString
Redefine appendFS in terms of appendFB

I think the old definition had a bug, although it probably never
actually bit us: It used lengthFS to work out how large the arguments
where, but lengthFS returns the number of characters, not bytes.
Add a separate FastZString type

FastStrings are now always UTF8-encoded.

There's no StringTable for FastZString, but I don't think one is needed.
We only ever make a FastZString by running zEncodeFS on a FastString,
and the FastStrings are shared via the FastString StringTable, so we get
the same FastZString from the IORef.
Fix dtraceTaskCreate

The tid argument was missing
Small refactoring
Rename a variable to avoid name conflicts in haddock
Define FastString on top of FastBytes

Although we currently break the abstraction a lot in the FastString
operations, this is a step towards ultimately being able to replace
FastBytes with ByteString.