Refactor INLINE pragmas

@AndreasK and I would like to refactor the way in which INLINE pragmas are represented in GHC: see !9621.

A driving motivation is to allow the combination of

• NOINLINE (or NOILINE[2]), to allow rules to fire
• INLINEABLE, to allow specialisation

There are a number of tickets about this point:

• #22629 (especially)
• #22637
• #18557
• #21036

A design I like is this:

Note [Pragmas for an Id]
~~~~~~~~~~~~~~~~~~~~~~~~
An Id can have three, orthogonal, user-specified pragmas, all packed into `PragInfo`

* `INLINE [n]`, `NOINLINE [n]`, `OPAQUE` (mutually exclusive): controls inlining. Fields
  * `inl_inline :: InlineSpec`.  
  * `inl_act :: Activation`: which phase inlining is active.
  * `inl_sat :: Maybe Arity`. Only relevant for `INLINE`
  * `INLINE` implies `INLINEABLE`; that is, it captures the original RHS of the binding, and sets `inl_stable`=`True`.
 
* `INLINEABLE`: makes GHC capture the original RHS of the binding, for use in possible specialisations;
  also, if GHC decides to inline the function, it'll inline this original RHS.  Fields:
  * `inl_stable` :: Bool
  * No phase on `INLINEABLE`.

* `CONLIKE`: treat applications of this Id as "expandable" like a data constructor.  See `Note [ ... ]`.  Fields:
  * `inl_rule :: RuleMatchInfo`