Look through ticks on arguments when doing eta-reduction

Doesn't seem to matter too much for the final result, but doing this
sooner rather than later can't be a bad idea.
Common sub-expression elimination ignores ticks

This pass definitely can reduce tick accuracy, as the whole point of
this is to merge source from different sources - which we then can not
distinguish anymore. Here we push the ticks to the referencing expression
instead, which is probably not too helpful for real-world tasks, but the
right thing to do.
Remove TickBoxOp

Dead code
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 here to just point into the middle of the
  existing Core code. This obviously means we will probably end up
  keeping this data alive for quite some time.

* We only annotate the interesting control flow points, which are
  bindings and case alternatives.

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