Inlining in Closure_conversion within local compilation unit

[Keryan-dev]

(From #181 and #162, relevant diff)

This allows for some inlining before reaching Simplify.

[Gbury]

I haven't reviewed everything, but as it stands, this PR does not have code to properly record the inlining decisions that are made, which must be fixed before merging (inlining reports are really useful sometimes to understand some inlining decision without having to add a lot of printing code in flambda).
I've added comments at the various points where inlining-report-related code should be added, but maybe I missed some. Also, considering that the heuristics are a bit different , there may be a need to add some new constructors to the inlining decisions.

[poechsel]

Would it be possible to:

• Refactor the bit that constructs the inlined body (I see there's already a CR suggesting to do it, how hard would it be?)
• Move the inlining decision (around line 176-226 and 1180-1210 in closure_conversion.ml) to be in simplifier/inliner? I'd prefer for these to the inliner logic to be in the same place.

[Keryan-dev]

Would it be possible to:

• Refactor the bit that constructs the inlined body (I see there's already a CR suggesting to do it, how hard would it be?)
• Move the inlining decision (around line 176-226 and 1180-1210 in closure_conversion.ml) to be in simplifier/inliner? I'd prefer for these to the inliner logic to be in the same place.

I agree the current code seems unsatisfactory, but I don't see anyway to refactor that in an elegant way.
The logic is almost exactly the same but some specificities are deeply embedded in both sides, making the usage of a functor tedious and hard to read.
In simplify, it needs informations of the dacc, and in Closure_conversion it passes around an acc through special modules (e.g. Let_with_acc) whose functions signatures (in particular, return types) are different from the Flambda ones.

Handled in 307a510

[lthls]

@Gbury I've dismissed your review, as the inlining reports should be correctly generated now. Feel free to complain again if something is still missing.

[lthls]

A small issue that I noticed while comparing the output with Closure: we don't share allocated constants in Closure_conversion at the moment. Running through simplify would take care of that, but we may want to look at introducing sharing in Closure_conversion too, when we go back to lifting in #164.

[mshinwell]

This is ok once @Keryan-dev and @lthls have reviewed the whole thing (including switching to the "new approach" for the factoring out of inlining code).

[lthls]

There are a few things that deserve to be fixed, I've left comments for them.

The handling of over- and under-applications can wait for later if you already know you'll rework it in one of your other PRs.