Source ticks (Stg)

This is basically just about continuing maintaining source ticks 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.
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 ticks for Core dumps

This patch allows source ticks 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.