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.