Arrows: collect evidence binders

Evidence binders were not collected by
GHC.HsToCore.Arrows.collectStmtBinders, hence bindings for dictionaries
were not taken into account while computing local variables in
statements. As a consequence we had a transformation similar to this:

    data Point a where Point :: RealFloat a => a -> Point a

    do
        p -< ...
        returnA -< ... (Point 0)

===> { Type-checking }

    do
        let $dRealFloat_xyz = GHC.Float.$fRealFloatFloat
        p -< ...
        returnA -< ... (Point $dRealFloat_xyz 0)

===> { Arrows HsToCore }

    first ...
    >>> arr (\(p, ()) -> case p of ... ->
            let $dRealFloat_xyz = GHC.Float.$fRealFloatFloat
            in case .. of () -> ())
    >>> \((),()) -> ... (Point $dRealFloat_xyz 0) -- dictionary not in scope

Now evidences are passed in the environment if necessary and we get:

===> { Arrows HsToCore }

    first ...
    >>> arr (\(p, ()) -> case p of ... ->
            let $dRealFloat_xyz = GHC.Float.$fRealFloatFloat
            in case .. of () -> $dRealFloat_xyz)
    >>> \(ds,()) ->
            let $dRealFloat_xyz = ds
            in ... (Point $dRealFloat_xyz 0) -- dictionary in scope

Note that collectStmtBinders has been copy-pasted from GHC.Hs.Utils.
This ought to be factorized but Note [Dictionary binders in ConPatOut]
claims that:

    Do *not* gather (a) dictionary and (b) dictionary bindings as
    binders of a ConPatOut pattern.  For most calls it doesn't matter,
    because it's pre-typechecker and there are no ConPatOuts.  But it
    does matter more in the desugarer; for example,
    GHC.HsToCore.Utils.mkSelectorBinds uses collectPatBinders.  In a
    lazy pattern, for example f ~(C x y) = ..., we want to generate
    bindings for x,y but not for dictionaries bound by C.  (The type
    checker ensures they would not be used.)

    Desugaring of arrow case expressions needs these bindings (see
    GHC.HsToCore.Arrows and arrowcase1), but SPJ (Jan 2007) says it's
    safer for it to use its own pat-binder-collector:

Accordingly to the last sentence, this patch doesn't make any attempt at
factorizing both codes.

Fix #18950