Refactor how rollup blocks are serialized in the storage

See marigold/tezos!59 (closed) for a first implementation of this refactoring.

The rationale is the following:

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”