Fix a nasty (and long-standing) FloatOut performance bug
The effect was that, in deeply-nested applications, FloatOut would
take quadratic time. A good example was compiling
programs/barton-mangler-bug/Expected.hs
in which FloatOut had a visible pause of a couple of seconds!
Profiling showed that 40% of the entire compile time was being
consumbed by the single function partitionByMajorLevel.
The bug was that the floating bindings (type FloatBinds) was kept
as a list, which was partitioned at each binding site. In programs
with deeply nested lists, such as
e1 : e2 : e3 : .... : e5000 : []
this led to quadratic behaviour.
The solution is to use a proper finite-map representation;
see the new definition of FloatBinds near the bottom of FloatOut.