Note [Eta-expand stable unfoldings]

For INLINE/INLINABLE things (which get stable unfoldings) there's a danger
of getting
   f :: Int -> Int -> Int -> Blah
   [ Arity = 3                 -- Good arity
   , Unf=Stable (\xy. blah)    -- Less good arity, only 2
   f = \pqr. e

This can happen because f's RHS is optimised more vigorously than
its stable unfolding.  Now suppose we have a call
   g = f x
Because f has arity=3, g will have arity=2.  But if we inline f (using
its stable unfolding) g's arity will reduce to 1, because <blah>
hasn't been optimised yet.  This happened in the 'parsec' library,
for Text.Pasec.Char.string.

Generally, if we know that 'f' has arity N, it seems sensible to
eta-expand the stable unfolding to arity N too. Simple and consistent.

Wrinkles

* See Historical-note [Eta-expansion in stable unfoldings] in
  GHC.Core.Opt.Simplify.Utils

* Don't eta-expand a trivial expr, else each pass will eta-reduce it,
  and then eta-expand again. See Note [Which RHSs do we eta-expand?]
  in GHC.Core.Opt.Simplify.Utils.

* Don't eta-expand join points; see Note [Do not eta-expand join points]
  in GHC.Core.Opt.Simplify.Utils.  We uphold this because the join-point
  case (bind_cxt = BC_Join {}) doesn't use eta_expand.