arityAnalProgram first try

but this analysis is too imprecise. Trying to further tailor it for tail
calls now.
Second try, this time only collect tail calls
Set the new IdInfo CalledArity

and use it in the simplifier to eta-expand the bindings approriately. We
get good code!
Some very prelimary explanations
Do not be too strict about things being tail-calls

It is ok to take the information from the scrunitee of a case, as long
as then, any information from the body is Nothing’ified.
Use same trick for calls as for cases:

Use information from the side where there is information to be used.
Consider less lets as interesting

if there is no eta-expansion possible, do not consider that. This is a
win because uninteresting lets can cause the code to choose the wrong
side in a case/app. But it could also be a loss if the interesting call
path passes through a fully expanded function. We'll see.
Add a unit test for CallArity

I put it all in one file because starting the GHC API is quite slow.
More CallArity to its own module
Add the usual flags -fcall-arity and -dddump-call-arity
Do not say “TailCall” in function names
Stop fixpointing when below exprArity
Add huge note to CallArity

(the module is now 50% notes).