Draft: Proto: Refactor the storage of Rollup blocks (RFC)

This is a RFC (Request For Comment) for a change I wanted to do for a long time now. I will let you read the commit message, that I tried to make as readable as possible.

The previous implementation was based on a graph of blocks.  Each
rollup level had a graph of current candidates stored in the storage.
This was bringing a lot of duplication in the storage, and was
potentially inefficient, because most of the time you don’t need the
whole graph to apply an operation.

With this patch, how the blocks are stored changes as follows:

  - Blocks are identified by their hashes
  - Each committed block is stored individually, and only refers to
  - their predecessor, not their successors
  - For each rollup level, we store a list of “block candidates”

We use the opportunity given by the refactoring to fix an existing
bug.  In the previous implementation, only the author of the deposit
of the finalized block was reimbursed.  Note that, in case of
rejection of the block, the deposits for the descendants of the fraud
block are not reimbursed.

TODO:

  - Produce [Remove_committed_block] when finalizing a block, if
    necessary
  - Clean-up of code older than [oldest_block_in_context]
  - Test-suite independent from [Lib_rollup]
  - [Lib_rollup.Generic] will need to be rewritten at some
    point. Start now?

As a side note: this commit completely breaks Lib_rollup.Generic. So naturally, it made me read the code there, and I am a bit preoccupied. I am maybe missing something, because the complete lack of documentation of the current implementation makes it hard to grasp, but my overall sentiment is that we probably need to rewrite it from scratch. Currently (1) everything lives in RAM, with no persistence at all, and (2) the code deals with things like code rejections that does not sound very optimistic to me. I would have assumed that a honest rollup node (we implement a honest node, right? 😅) would just exit with an error in case one of its block is rejected, because it’s not like it is something from what it can recover. My proposal would be to have a rollup node with just a linear history, that would send rejection when it can, and yeah, fails when it is rejected. It already made the user loose money, we don’t want it to continue ahah.

Anyway, lots to discuss about.