Source notes (Core support)

This patch introduces "SourceNote" tickishs that carry a reference to the
original source code. They are meant to be passed along the compilation
pipeline with as little disturbance to optimization processes as possible.

Generation is triggered by command line parameter -g. It's free and
fits with the intended end result (generation of DWARF). Internally we
say that we compile with "debugging", which is probably at least
slightly confusing given the plethora of other debugging options we have.

Note that this pass creates *lots* of tick nodes. We take care to
remove duplicated and overlapping source ticks, which gets rid of most
of them. Possible optimization could be to make Tick carry a list of
Tickishs instead of one at a time.

Keeping ticks from getting into the way of Core transformations is
tricky, but doable. The changes in this patch produce identical Core
in all cases I tested (nofib). We should probably look for a way to
make a test-case out of this.
Generalized Coverage pass to allow adding multiple types of Tickishs

This allows having, say, HPC ticks, automatic cost centres and source
notes active at the same time.
Source notes (CorePrep and Stg support)

This is basically just about continuing maintaining source notes after
the Core stage. Unfortunately, this is more involved as it might seem,
as there are more restrictions on where ticks are allowed to show up.

Design decisions:

* We replace the StgTick / StgSCC constructors with a unified StgTick
  that can carry any tickish.

* For handling constructor or lambda applications, we generally float
  ticks out.

* However for bindings we float ticks inwards and even discard them for
  constructors, as there is no good place to put them (mkTopStgRhs,
  mkStgRhs). The only real argument against it would be that for
  non-top-level bindings, the allocation cost ends up not being covered
  by the tick in question.

* Where CorePrep floats out lets, we make sure to wrap them in the same
  spirit as FloatOut.
Strip source ticks from iface code if DWARF is disabled

They would be unneeded at minimum.
Source notes from Core dumps

This patch allows source notes to refer to --ddump-to-file Core dumps, so
we can have debugging data refer directly to places in the Core. The
implementation is slightly tricky, as we couldn't find a way to get Pretty
to generate line number information for us. Instead, we now generate
"annotations" into the dump that get stripped out later, yielding line
numbers as we go along.
Core notes

These tickishs are meant to carry the (simplified and prepared) Core
through the later compilation stages.

Notes:

* Core notes are only useful in certain scenarios (mostly profiling),
  and will end up taking up significant space in object files. We therefore
  use another GHC flag (-fsave-core) to decide whether we annotate them or
  not.

* Annotations happen after CorePrep. This is slightly tricky, as CoreToStg
  moves ticks around even after this point. We have to be careful to ensure
  ticks end up where we intend them to be.

* We take the easy route to just "point" into the Core code directly.
  This is slightly awkward given that Core is normally a more stright-
  forward data structure. We have to short-circuit Eq/Ord, for example.

* We only annotate the interesting control flow points, which are
  either top-level or let binding bodies as well as case branches.

* In order to establish an identity and later perform sub-expression
  checks, we safe a binder (of the binding or case) and the case
  constructor (if applicable, otherwise __DEFAULT).
Source notes (Cmm support)

This patch adds CmmTick nodes to Cmm code. On their own these ticks are
not useful yet, as there will be many blocks that lack annotation - and
we have no way of deriving them.

Notes:

* We use this design over, say, putting ticks into the entry node of all
  blocks, as it seems to work better alongside existing optimisations.
  Now granted, the reason for this is that currently GHC's main Cmm
  optimisations seem to mainly reorganize and merge code, so this might
  change in the future.

* We have the Cmm parser generate a few source notes as well. This is
  relatively easy to do - worst thing is that it blows up the CmmParse
  implementation a bit.
Tick scopes

This patch solves the scoping problem of CmmTick nodes: If we just put
CmmTicks into blocks we have no idea what exactly they are meant to cover.
Here we introduce nested scopes, represented as lists of uniques. The
"nesting" relation is given by the subset relation. For example a tick
declared in a block with, say, scope [b,a] now scopes over all blocks
that have at least a tick scope of [b,a], so for example also [c,b,a].

Notes:

* This makes it easy to express most optimisations: It is both easy to
  generate new blocks that share all ticks with existing blocks. It is
  especially possible to merge blocks to have combined contexts, simply
  by merging the scope lists. If this happens, we actually end up with
  an (acyclic) scope graph instead.

* Given that the code often passes Cmm around "head-less", we have to
  make sure that its intended scope does not get lost. To keep the amount
  of passing-around to a minimum we define a CmmAGraphScoped type synonym
  here that just bundles the scope with a portion of Cmm to be assembled
  later.

* We introduce new scopes at somewhat random places, aligning with
  getCode calls. This works surprisingly well, but we might have to
  add new scopes into the mix later on if we find things too be too
  coarse-grained.
Add Sp unwind information to Cmm

This is meant as a tool for the debugger to determine past values of
registers, most critically the stack pointer Sp.

* We declare yet another new constructor for CmmNode - and this time
  there's actually little choice, as unwind information can and will
  change mid-block. We don't actually make use of these capabilities,
  and back-end support would be tricky (generate new labels?), but it
  feels like the right way to do it.

* Even though we only use it for Sp so far, we allow CmmUnwind to specify
  unwind information for any register. This is pretty cheap and could
  come in useful in future.

* We allow full CmmExpr expressions for specifying unwind values. The
  advantage here is that we don't have to make up new syntax, and can e.g.
  use the WDS macro directly. On the other hand, the back-end will now
  have to simplify the expression until it can sensibly be converted
  into DWARF byte code - a process which might fail, yielding NCG panics.
  On the other hand, when you're writing Cmm by hand you really ought to
  know what you're doing.
Debug data extraction (NCG support)

The purpose of the Debug module is to collect all required information
to generate debug information (DWARF etc.) in the back-ends. Our main
data structure is the "debug block", which carries all information we have
about a block of code that is going to get produced.

Notes:

* Debug blocks are arranged into a tree according to tick scopes. This
  makes it easier to reason about inheritance rules. Note however that
  tick scopes are not guaranteed to form a tree, in which case we end
  up discarding some information here. This is however not too relevant
  in realistic scenarios, I feel.

* This is also where we decide what source location we regard as
  representing a code block the "best". The heuristic is basically that
  we want the most specific source reference that comes from the same file
  we are currently compiling. This seems to be the most useful choice in
  my experience.

* We are careful to not be too lazy so we don't end up breaking streaming.
  Debug data will be kept alive until the end of codegen, after all.

* We change native assembler dumps to happen right away for every Cmm group.
  This simplifies the code somewhat and is consistent with how pretty much
  all of GHC handles dumps with  respect to streamed code.
Generate .loc/.file directives from source ticks

This generates DWARF, albeit indirectly using the assembler. This is
the easiest (and, apparently, quite standard) method of generating the
.debug_line DWARF section.

Notes:

* Note we have to make sure that .file directives appear correctly
  before the respective .loc. Right now we ppr them manually, which makes
  them absent from dumps. Fixing this would require .file to become a
  native instruction.

* We have to pass a lot of things around the native code generator. I
  know Ian did quite a bit of refactoring already, but having one common
  monad could *really* simplify things here...

* To support SplitObjcs, we need to emit/reset all DWARF data at every
  split. We use the occassion to move split marker generation to
  cmmNativeGenStream as well, so debug data extraction doesn't have to
  choke on it.
Generate DWARF info section

This is where we actually make GHC emit DWARF code. The info section
contains all the general meta information bits as well as an entry for
every block of native code.

Notes:

* We need quite a few new labels in order to properly address starts
  and ends of blocks.w1

* There is no DWARF language ID for Haskell, so we arbitrarily choose a
  number derived from dW_LANG_lo_user and 'hs'. This feels like the right
  thing to do, even though sometimes DWARF tools get confused by any
  unknown value in this field.

* Thanks to Nathan Howell for taking the iniative to get our own Haskell
  language ID for DWARF!
Generate DWARF unwind information

This is telling debuggers such as GDB how to "unwind" a program state,
which allows them to walk the stack up.

Notes:

* The code is quite general, perhaps unnecessarily so. Unless we get more
  unwind information, only the first case of pprSetUnwind will get used -
  and pprUnwindExpr and pprUndefUnwind will never be called. It just so
  happens that this is a point where we can get a lot of features
  cheaply, even if we don't use them.

* When determining what location to show for a return address, most
  debuggers check the map for "rip-1", assuming that's where the "call"
  instruction is. For tables-next-to-code, that happens to always
  be the end of an info table. We therefore cheat a bit here by shifting
  .debug_frame information so it covers the end of the info table, as
  well as generating a .loc directive for the info table data.

  Debuggers will still show the wrong label for the return address, though.
  Haven't found a way around that one yet.
Generate .debug.ghc section

The conversion to DWARF is always lossy, so we put all the extra
bits of information into an extra object file section (.debug-ghc).

Notes:

* We use the eventlog format. This might seem like a slightly arbitrary
  choice, but makes it easy to copy debug data into eventlogs later in
  order to do profiling. In the meantime, it's well-defined and extensible,
  so until we run out of record IDs there's no strong reason against it
  either.

* Core notes now cause the complete Core to be copied. We are reasonably
  smart about this: We never emit a piece of Core twice, and use a compact
  binary representation for most Core constructors.

  On the other hand, we just pretty-print types as well as names and emit
  them as strings. This can sometimes lead to packets becoming too large
  for the eventlog format to handle (we had types break the 20k loc mark).
  In order to not run into these kinds of problems, we just omit packets
  that are longer than a certain threshold.

* The amount of data generated here is significant. We therefore use faily
  low-level generation code using memory buffers. Furthermore, we include
  the data as a string, escaped using another well-optimized low-level
  routine. All this might make it hard to read debug data in the assembly,
  but is absolutely required for debugging not to become a significant
  resource hog.

* The eventlog IDs used here were chosen primarily to avoid collisions.
  If this code gets merged they should be adjusted appropriately.