MultiLayerModules flip flops by +-2.5%

As can be seen in http://hsyl20.fr:4222/chart/x86_64-linux-deb9-hadrian#MultiLayerModules_normal_ghc_alloc, MultiLayerModules is a stable benchmark for the most. There was a ~2.5% ghc/alloc improvement a while ago that judging from the commit message might have made sense, but otherwise it's quite stable.

But recently, a couple of unrelated MRs !1866 (closed), !4412 (closed), !4478 (closed), !4757 (closed), !4589 (closed) saw an 2.5% increase back to what we had. I don't think any of the MRs can be blamed for that. There must be some other underlying issue.

While sifting through ticky profiles, it appeared that !1866 (closed) somehow had more calls to Data.IntMap.Internal.$winsert. Here are some ideas why:

• An inlining heuristic flipped. Relatively unlikely for some of the MRs, like !4757 (closed).
• Some UniqFM-related shenanigans. More/less allocated uniques might have a huge effect on MultiLayerModules, because it does nothing interesting besides dependency analysis. Maybe some Bin node of basically all IntMaps overflowed, because the int ranges are, e.g., 13...34 instead of 7..28.
• In !1866 (closed), I noticed that interface file sizes went up slightly. But that can't be the reason for the regression, because I could also reproduce the regression when I literally just rebased d17e2a3e, which was fine before the rebase.

I'm opening this ticket to redeem said MRs from further investigation into the matter.