Add code action for inlining

[jfeser]

This PR adds an inlining code action for non-top-level let bindings. For example,

let test y =
  let x = y + 1 in
      ^
  x + 2

turns into

let test y =
  let x = y + 1 in
  (y + 1) + 2

after inlining.

Caveats:

• The inlining context can shadow bindings in the body, which changes the meaning of the inlined code. I.e., this transformation isn't sound. We should at least be able to use Merlin to detect this and block the action, but I'm not sure how.
• Right now I'm using Untypeast followed by Pprintast to turn the body of the let into a string. This means that comments are stripped and the inlined code contains expanded PPXes. This should be fixable by using the source code the body, but it requires a bit more care when inlining functions.
• The original definition is not removed. It should be unused after inlining, so it'll be a target for the "remove unused" action.

[ulugbekna]

This is great! Thanks! I will review it this week.

The inlining context can shadow bindings in the body, which changes the meaning of the inlined code. I.e., this transformation isn't sound. We should at least be able to use Merlin to detect this and block the action, but I'm not sure how.

Perhaps, @voodoos could advise as an expert here.

Otherwise, you could find quite a bit of help from people on ocaml discord (eg octachron is quite active and has expertise in the typechecker) or ocaml discourse, which also may attract many enthusiasts

First things that come to mind are to

• either capture Path.ts of (free) variables in the let binding, and make sure that those variables keep referencing the same Path.ts when inlined. Variables also have Env.t that could be used to see where they're defined. I'll think about this more on Friday.
• or see if any binding after the one being inlined shadows its free variables (how to compute the free variables though)

[jfeser]

Also, inlining is always unsound in OCaml, since it can duplicate side effects. But I think the issue with shadowing is more likely to introduce subtle bugs.

[ulugbekna]

Thanks! It was an interesting read; the feature seems to work well.

I will also think what we can do with shadowed variables and side-effects.

[jfeser]

Comments should all be addressed.

[jfeser]

Inlining now does a best-effort round of beta reduction after inlining a function. It also works on top level let bindings.

[rgrinberg]

Looks good.

@ulugbekna are you still reviewing?

Let's ping @voodoos so that he has the feature and the issues with shadowing in the back of his mind. Perhaps merlin can help us make this more robust one day?

[ulugbekna]

@ulugbekna are you still reviewing?

I was off past two weeks. Will finish reviewing asap.

[ulugbekna]

Thanks again for this awesome work! I especially liked thoroughness and visual explicitness of tests. I left a couple of nits that definitely don't block this PR. Feel free to merge or let us know when you'd like to merge. I think it's best to squash before merging, btw.

[ulugbekna]

I used this code action twice today to inline top-level functions, and it worked great! If not for this, inlining would be quite annoying for those fns. Thanks again! :-)

Let me know if you need any help with "extract" code action PR!