Intial bip34 like for versioning

[Leo-Besancon]

• document all added functions
• try in sandbox /simulation/labnet
• unit tests on the added/changed features
  • make tests compile
  • make tests pass
• add logs allowing easy debugging in case the changes caused problems
• if the API has changed, update the API specification

[Leo-Besancon]

Some notes:

• How and when do we "refuse" a block?

  • When the block version is not "compatible" with our "active version"
  • See the consensus' code, e.g. in massa-consensus-worker / src / controller.rs:

  fn mark_invalid_block(&self, block_id: BlockId, header: SecureShare<BlockHeader, BlockId>) { ... }

• Within a block, do we need an "announced version" AND an "active version"?

  • Otherwise, we could have a blockV1 that announce version 3, a blockV2 that announce version 3, and the two blocks are not compatible.
  • It's the main idea behind the "1" "1/2" "2" graph.

• What do we do in case the maximal clique changes?

  • We may need to keep track of versions in an HashMap<BlockId, u32> instead of a VecDeque in order to quickly roll back the computations?
  • See how the candidate / final states are made.
  • Or do we only consider finalized blocks?

• Do we need to customize N/T for each proposal?

  • Currently, it's just a const. If we need to customize it for each version, it would impact the struct used to keep track of the announced versions

• How do we handle failed proposals?

• Do we change the parents draws to prefer parents announcing the same version?
  -Probably a good idea!

[Leo-Besancon]

This PR is outdated, the follow-up is at #3664