Fix over-eager inlining in SimpleOptwip/T19347

In GHC.Core.SimpleOpt, I found that its inlining could duplicate
an arbitary redex inside a lambda!  Consider (\xyz. x+y).  The
occurrence-analysis treats the lamdda as a group, and says that
both x and y occur once, even though the occur under the lambda-z.
See Note [Occurrence analysis for lambda binders] in OccurAnal.

When the lambda is under-applied in a call, the Simplifier is
careful to zap the occ-info on x,y, because they appear under the \z.
(See the call to zapLamBndrs in simplExprF1.)  But SimpleOpt
missed this test, resulting in #19347.

So this patch
* commons up the binder-zapping in GHC.Core.Utils.zapLamBndrs.
* Calls this new function from GHC.Core.Opt.Simplify
* Adds a call to zapLamBndrs to GHC.Core.SimpleOpt.simple_app

This change makes test T12990 regress somewhat, but it was always
very delicate, so I'm going to put up with that.

In this voyage I also discovered a small, rather unrelated infelicity
in the Simplifier:

* In GHC.Core.Opt.Simplify.simplNonRecX we should apply isStrictId
  to the OutId not the InId. See Note [Dark corner with levity polymorphism]

It may never "bite", because SimpleOpt should have inlined all
the levity-polymorphic compulsory inlnings already, but somehow
it bit me at one point and it's generally a more solid thing
to do.

Fixing the main bug increases runtime allocation in test
perf/should_run/T12990, for (acceptable) reasons explained in a
comement on

Metric Increase:
    T12990

0 files changed, 0 insertions, 0 deletions