Source notes (Cmm)

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 control
  flow backwards: the context of every block is a block that has to have
  been executed prior. In contrast to looking at control flow directly
  (which we thought about at some point) this approach has the advantage
  that it always yields a unique parent block and directly corresponds
  to STG structure.

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

Conflicts:
	compiler/cmm/PprCmm.hs
Refactor common_block

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