Ticket #19360 showed up a terrible bug in the occurrence analyser,
in a situation like this

   Rec { f = g
       ; g = ..f...
         {-# RULE g .. = ...f... #-}  }

Then f was postInlineUnconditionally, but not in the RULE (which
is simplified first), so we had a RULE mentioning a variable that
was not in scope.

This led me to review (again) the subtle loop-breaker stuff in the
occurrence analyser. The actual changes are few, and are largely
simplifications.  I did a /lot/ of comment re-organising though.

There was an unexpected amount of fallout.

* Validation failed when compiling the stage2 compiler with profiling
  on. That turned to tickle a second latent bug in the same OccAnal
  code (at least I think it was always there), which led me to
  simplify still further; see Note [inl_fvs] in GHC.Core.Opt.OccurAnal.

* But that in turn let me to some strange behaviour in CSE when ticks
  are in the picture, which I duly fixed.  See Note [Dealing with ticks]
  in GHC.Core.Opt.CSE.

* Then I got an ASSERT failure in CoreToStg, which again seems to be
  a latent bug.  See Note [Ticks in applications] in GHC.CoreToStg

* I also made one unforced change: I now simplify the RHS of a RULE in
  the same way as the RHS of a stable unfolding. This can allow a
  trivial binding to disappear sooner than otherwise, and I don't
  think it has any downsides.  The change is in
  GHC.Core.Opt.Simplify.simplRules.