Matching should see through lambdas at the statement level

From https://code.google.com/p/ndmitchell/issues/detail?id=471, @tomprince says:

The code

> parensF f = \a b -> parens (f a) (f b)

gives suggestions

>  parensF f a b = parens (f a) (f b)
>  parens `Data.Function.on` f

but if I apply the first, getting

> parensF f a b = parens (f a) (f b)

it no longer gives me the second suggestion, which would now be

> parensF f = parens `Data.Function.on` f

Clearly both original suggestions are beneficial, but the first one is rather obvious, and likely caught and applied by hand before running hlint. That means that the second suggestion, which teaches the library, won't ever be shown.

@ndmitchell replies:

On further analysis, I think the real fix is that the matcher should be rewritten so that:

foo a b c = ....

Is analysed as:

foo = \a b c -> ...

And then any remaining lambdas are moved back at the end. That makes it a lot more general than just the on suggestion.

No source file or test is named. Start by locating the statement-level matcher and reproduce the two parensF examples from the issue. Done means matching analyzes function bindings through their implicit lambdas, while preserving the intended suggestions after remaining lambdas are moved back.