Fix a bug in CSE, for INLINE/INLNEABLE things

Previusly we simply weren't doing CSE at all on things
whose unfolding were not always-active, for reasons explained
in Note [CSE for INLINE and NOINLINE].  But that was bad!
Making something INLNEABLE meant that its RHS was no longer
CSE'd, and that made some nofib programs worse.

And it's entirely unnecessary.  I thoguht it through again,
wrote new comments (under the same Note), and things are
better again.
Comments, white space, and rename "InlineRule" to "stable unfolding"

The "InlineRule" is gone now, so this is just making the comments line
up with the code.  A function does change its name though:
   updModeForInlineRules  -->  updModeForStableUnfoldings
When finding loop breakers, distinguish INLINE from INLINEABLE

Previously INLINE and INLINEABLE were treated identically, but it's
crucial that we don't choose a wrapper (INLINE) as a loop breaker,
when it is mutually recursive with an INLINEABLE worker.
Better specImport discarding message (again)
Give the worker for an INLINABLE function a suitably-phased Activation

See Note [Activation for INLINABLE worker].  This was preventing
Trac #6056 from working.
Finally!  Test Trac #6056
Performance improvement of the compiler itself

This is a result of one of these, or a combination
  002b7a2b * Give the worker for an INLINABLE function a suitably-phased Activation
  ca666b8b * When finding loop breakers, distinguish INLINE from INLINEABLE
  a98c9c5e * Fix a bug in CSE, for INLINE/INLNEABLE things

Some changes are quite big: for bytes_allocated we have
  T6048: 13% below expected
  T5837: 15% below expected
  T3064:  5% below expected

Of course, these might have already been close to their lower
threshold, so perhaps not all the improvement is from here.
But it is good news all the same.