SCORU: Add storage of commitments

Context

Adds storage of commitments (but not of disputes/refutations).

Commitments are stored directly in the Context rather than using an off-chain structure as we do for the inbox. They are however stored as a Merkle DAG, which allows switching to such an approach later if warranted by benchmarks.

The full sc_rollup storage schema now looks like:

sc_rollup
  index
    <sc_rollup_address : Sc_rollup_address.t >
      boot_sector : string
      kind : Kind.t
      
      commitments <commitment_hash> : Commitment.t
      last_final_commitment : Commitment_hash.t
      stakers <pkh : Public_key_hash.t > : Commitment_hash.t
      stakers_size : int32
      commitment_stake_count <commitment_hash : Commitment_hash.t > : int32

• commitments is a Merkle tree of all current commitments. Note that we store (child -> parent) references (a la Git), not the other way around.
• last_final_commitment points to the finalized commitment (which includes the last L2 state and the Tezos level in which the corresponding set of messages were added to the Inbox).
• stakers maps accounts (represented by Public_key_hash.t) to commitments.

Taking the Git analogy one step further, stakers are individual branches, and last_final_commitment is the agreed-upon main branch.

For efficiency, we also store:

• stakers_size - the current number of stakers
• the number of current stakers per commitment

Note that the last two are completely determined by stakers and commitments.

The design doc for storage is slightly out of date. I (@hans.hoglund) will update the doc once this MR is approved.

Depends on !4248 (merged)

Fixes #2107 (closed), #2118 (closed).

Will make a separate MR for #2106 (closed) adding invariant-preserving logic and unit tests.

TODO

• document invariants
• add tests for corner cases (unset keys, broken invariants)
• cleanup above desc of high-level invariant-preserving logic

Manually testing the MR

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, the Development Version section of CHANGES.md for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR