DmdAnal: Kill `is_thunk` case in `splitFV`

The splitFV function implements the highly dubious hack described in Note [Lazy und unleashable free variables] in GHC.Core.Opt.DmdAnal. It arranges it so that demand signatures only carry strictness info on free variables. Usage info is released through other means, see the Note. It's purely for analysis performance reasons.

It turns out that splitFV has a quite involved case for thunks that produces slightly different usage signatures and it's not clear why we need it: splitFV is only relevant in the LetDown case and the only time we call it on thunks is for top-level or local recursive thunks.

Since usage signatures of top-level thunks can only reference other top-level bindings and we completely discard demand info we have on top-level things (see the lack of setIdDemandInfo in dmdAnalTopBind), the is_thunk case is completely irrelevant here.

For local, recursive thunks, the added benefit of the is_thunk test is marginal: We get used-multiple-times in some cases where previously we had used-once if a recursive thunk has multiple call sites. It's very unlikely and not a case to optimise for.

So we kill the is_thunk case and inline splitFV at its call site, exposing isWeakDmd from GHC.Types.Demand instead.

The NoFib summary supports this decision:

            Min           0.0%     -0.0%
            Max           0.0%     +0.0%
 Geometric Mean          -0.0%     -0.0%