Separate compilation: generate and use cross module information regarding function arity

[vouillon]

We could improve the code generated when compiling cmo files if we knew the arity of the functions exported by each module. This would allow to call functions directly rather than going through an helper function which manages currying. When the function is known, one could also export the corresponding Wasm function so that it can be directly accessed without going through the toplevel module and the closure.

In order for this to work with submodules and functors, we need to know which blocks are immutable (see #91). Alternatively, in the case of functors, it might be possible to refine the escape analysis to recognize that a fresh block returned by a function cannot be mutated by other callers.

This is wasm_of_ocaml counterpart to ocsigen/js_of_ocaml/issues/550. @hhugo has written a draft implementation for js_of_ocaml in ocsigen/js_of_ocaml#1594.

[OlivierNicole]

Does this require modifying ocamlc?

[vouillon]

Without modifying ocamlc, we can get the arity of functions at toplevel, and maybe in functors. If ocamlc is modified, so that we know with blocks are immutable, we can also deal with submodules. (Otherwise, we don't know whether a block containing functions is a module or a structure with possibly mutable fields.)

[hhugo]

Here is a experimental (and WIP) support for shapes inside dune https://github.com/ocaml/dune/pull/10767. I've just rebased it on top of the wasm support in dune.