Let lib_validation work on in-memory contexts

Context

This MR is the first step towards allowing to run a node on a mocked, in-memory storage. It allows to run lib_validation on an in-memory context rather than exclusively on the on-disk implementation.

The MR is structured in three segments:

• The first, main segment extends lib_context/memory with operations required for lib_validation. We do so in the following sub-steps:

  • move the on-disk implementation, currently at the root of lib_context, in the tezos-context.disk sub-library. tezos-context.disk is re-exported as tezos-context in order to not have to modify client code.
  • extract a TEZOS_CONTEXT module type out of tezos-context.disk that can be reasonably implemented by tezos-context.memory
  • make tezos-context.memory implement this module type. This is where most of the non-trivial diff of this MR comes from. The code is essentially a copy of that of tezos-context.disk, to the point that I wonder whether we could not factor the implementation. I'm not enough of an Irmin expert to do that.

• The second segment creates in lib_protocol_environment a new Context_ops module (presented as a sub-library) that presents a unified interface over tezos-context implementations. (This module is in fact moved away from post-tenderbake lib_delegate, where it was used already for testing purposes using the mockup baker; our move allows to deduplicate this code).

• The last segment uses Context_ops in lib_validation instead of direct calls to the tezos-context.disk implementation. This necessitates to perform some context wrapping in other parts of the shell as the type boundary between abstract and concrete context implementation is moved to the clients of lib_validation. These wrappings are expected to disappear in followup work.

I strongly recommend commit by commit, or at least segment-by segment reviewing.

Manually testing the MR

This MR is essentially a refactor MR, the behaviour of existing code is unchanged.

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