Tree_encoding: Reorganize the dependencie tree of 'lib_scoru_wasm'

Context

Before to this patch, the dependency tree of lib_scoru_wasm is straightforward.

lib_webassembly (provide lazy containers) <- lib_scoru_wasm (provide tree encoding)

The caveat is that the encoding of the types introduced in lib_webassembly are defined in lib_scoru_wasm… and therefore cannot be easily tested in the official WASM test-suite (in a decode, eval, encode loop).

This patch is the first step towards being able to test the tree encoders developed for the PVM in the WASM test-suite.

We introduce two libraries,

• lazy-containers introduces laz maps, lazy vectors, and chunked byte vectors
• tree-encoding introduces the tree encoders (including for the lazy containers)

The rest of the code base is unchanged, in particular the tree encoding are still defined in lib_scoru_wasm. I propose to move them in a followup MR.

Incidentally, close #3457 (closed) in favor of Tree_encoding (in place of Merklizer).

Rebasing on top of this MR

• The tree-encoding library only exports one module Tree_encoding, which contains two main module: the TREE module type (old fully qualified name was Tezos_scoru_wasm.Tree.S), and the functor Make. Note that TREE is a limited subset of the Irmin contrext tree module type, rather than an alias as before. This will impact you only if you have modified the tree-encoding lib and use a function that was not used before. In such a case, add it to TREE.
• There were two names competing for the module resulting in the use of Make: Merklizer and EncDec. The winner is… Tree_encoding. So basically,

module Tree_encoding = Tree_encoding.Make (_)

Is the suggested way to move forward.

Note that the plan is then to make a follow-up MR will move all WASM-specific tree encoding defined in lib_scoru_wasm in lib_webassembly. This might impacts you as well.

Manually testing the MR

No semantic change. CI shall prevail.

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR