Precise semantics for value slots

The basics semantics for functions and value slots is simple: it is the same thing as a block field.

But following that semantics limits too much some closure cleaning optimisations. For instance:

let code_f y env = y + env.x
let closure_f = { x -> 1; f -> code_f }

Can be simplified into

let code_f' y _env = y + 1
let closure_f = { x -> 1; f -> code_f' }

But it can't be simplified further by removing the x field

let code_f' y _env = y + 1
let closure_f = { f -> code_f' }

For that to be valid, we need to know that no code could ever access the x field from closure_f. In practice such case can happen if code_f gets inlined without being optimized enough.

But if closure_f escapes from the current file (by either returning it in the main module or passing it as argument to a function from another module), it could looks like we can't remove that field without changing the semantics of the value closure_f

But we can also slightly change the semantics of value slots: all value slots are created fresh. A new slot x would necessarily come from a derivative of closure_f (or some other closure from which it derives). Defining precisely the semantics that correspond to that invariant is a bit tricky, and we don't have a good formulation for that yet.