Implement CallArity analysis

This analysis finds out if a let-bound expression with lower manifest
arity than type arity is always called with more arguments, as in that
case eta-expansion is allowed and often viable. The analysis is very
much tailored towards the code generated when foldl is implemented via
foldr; without this analysis doing so would be a very bad idea!

There are other ways to improve foldr/builder-fusion to cope with foldl,
if any of these are implemented then this step can probably be moved to
-O2 to save some compilation times. The current impact of adding this
phase is just below +2% (measured running GHC's "make").
Add a unit test for CallArity

This also sets precedence for testing internals of GHC directly, i.e.
without trying to come up with Haskell code and observable effects.
Let's see how that goes.

I put all the tests (including those where the analysis could do better)
in one file because starting the GHC API is quite slow.
Update test cases due to call arity

Some nice improvements on already succeeding test cases (#876, #7954
and #4267)

Test #149 needed a little change, lest call arity causes a allocation
change that we do not want to test here.
Note [Eta expansion in match]
Replace forall'ed Coercible by ~R# in RULES

we want a rule "map coerce = coerce" to match the core generated for
"map Age" (this is #2110).
In CoreSubst, optimize Coercible values aggressively

just like boxed type equalities.
In simpleOptExpr, unfold compulsary unfoldings

such as that of coerce.
Add Case TyConAppCo to match_co
Test case for RULE map coerce = coerce

(This tests #2110.)
Use exprIsLambda_maybe in match

when matching a lambda in the template against an expression. When
matching, look through coercions (only for value lambdas for now), and
look through currently active unfoldings, if these are undersaturated,
i.e. produce a lambda.

This replaces the existing, somewhat fishy eta-expansion.
Test case: Looking through unfoldings when matching lambdas
Remove eta-expansion in Rules.match

It validates and nofib shows no change, so possibly dead code. Removing in the
interest of code cleanliness, someone disagrees please revert (and preferably
add a testcase, or at least describe the situation this is important in in a
Note).