Remove TickBoxOp

Dead code
Refactor common_block

Not too interesting, just trying to get it out of the diff.
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.

Design decisions:

* Use -g for generation of source ticks. It's free and fits with the
  intended end result (generation of DWARF).

* Using the name "Debug" internally for the whole framework. Might create
  confusion with the plethora of other debugging options, generally
  referring to debugging GHC.

* The coverage pass can only produce one of HPC, SCC or source notes. That
  is probably unnecessarily restrictive.

* This pass creates *lots* of tick nodes. This patch already removes
  duplicated and overlapping source ticks, which gets rid of something
  around 80% of them. Possible optimization could be to make Tick carry
  a list of Tickishs instead of one at a time.

* We count the number of times a source note is floated out - as per the
  causality semantics any source notes with a count > 0 is redundant
  strictly speaking, but I find it useful to keep them around.

* Keeping ticks from getting into the way of optimisations is tricky, but
  doable. The changes in this patch produce identical Core in all cases
  I tested (nofib). It would be nice to make a test-case out of this.
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.
Core notes

These tickishs are meant to carry the (simplified and prepared) Core
through the later compilation stages. This involves a few slightly awkward
constructions:

* We take the easy route to just reference the Core code directly.

* 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 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.
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.
CmmContext nodes

This is the plumbing to allow us to define a proper association scheme
for blocks that have no source ticks on their own. The idea is basically
that all but top-level entry blocks are created in the *context* of
another block, and therefore are covered by any ticks of that block or,
in turn, its parents.

Notes:

* As explained in the paper, this is basically about following causality
  backwards: the context of every block is a block that *caused* its
  evaluation in the first place. Note that this does neither have to
  be the block that called it, nor even the dominator if you put it as
  a graph problem. Therefore we need more information, which the context
  nodes provide.

* Contexts are declared "forward": We insert the CmmContext node into
  the parent block, declaring itself context of the labelled other block.
  This means that if blocks are merged we have to make no corrections:
  The result block will become the context of the blocks referenced from
  either source block. On the other hand, eliminating blocks might now
  leave superflous CmmContext nodes behind.

* We must also take care to not copy or duplicate CmmContext nodes.
  We especially can't declare them as okToDuplicate in CmmContFlowOpt,
  which sadly yields less optimal code, even though I think most of it
  gets fixed in the NCG.

* Finally, the context relationships can and will refer to blocks in
  other procedures - and I think it's not even guaranteed that we only
  reference entry blocks. This requires back-ends to consider whole
  Cmm groups when putting the context tree together.
Emit ticks before heap check

This makes sure that we get the ticks in entry blocks, and properly cover
the cost of the heap check. This is generally the right thing to do as
long as the tick in question doesn't track entry counts: Those would be
wrong due to re-execution of the entry block after a failed heap check.
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

This module handles collection all the pieces of debug information we
need for debug information. We organise them as a tree so it is easy
to follow context relations.

Note that we are making sure that we are not lazy in cmmDebug: This
information will be retained throughout the back-end, so we could easily
keep Cmm code alive here.