SCORU: stake on a commitment rather than on a branch

Context

Closes #4372 (closed), #4447 (closed), #4394 (closed)

The linear traversals are critically bad. They explode the gas, it's impossible to refine to a stake too recent and to remove an old commitment. This questions the whole mechanism of branches.

After thinking it over with @yrg @sribaroud and @lthms we found a workaround on the staking's mechanism:

Instead of staking on a branch, you stake on a commitment that belongs to a branch. In the normal setup, a "valid" operator will send a commitment to each commitment period and create a branch-like.

On master, you will see the staking's tree like this:

 lcc                 .
                   /   \ 
 l0               .     .
                / |     |
 l1           .   .     .
              |   |     |
 l2           .   .     .
              A   B     C

Let's say that branches A, B and C only has one staker. To cement the branch C, you'll need to resolve the conflict against the staker of branches A and B. You'll play the game at l0 against both stakers and it will completely remove the branches A and B. Therefore, you can cement C and everything is fine.

 lcc-1                .
                      |  
 lcc                  .
                      |
 l1                   .
                      |
 l2                   .
                      C

With the new mechanism, you don't think in term of branches, but in term of inbox levels. We know at which levels we expect a commitment, and that's a strong property to use. Let's say the scenario is the same as above. But when A will win the game against B and C, the commitment's tree will remain as is, B and C will only be slashed. When A will cement the commitment at l0, he will find no active opponents on this inbox level, and all "unstaked" commitments will be removed. The tree will look like:

 lcc-1                .
                       \ 
 lcc                    .
                        |
 l1           .   .     .
              |   |     |
 l2           .   .     .
              A   B     C

The rest of the branches A and B will be considered as dangling, i.e. no active stakers on it, and not an descendant of the lcc. The dangling commitments of l1 will be removed during the cementing of l1, same for l2 and so on.

owner: @vch9

Manually testing the MR

Added and rewrited a lot of tests (especially the unit ones). It makes the merge request very large but as it is an import change, we need to strongly validate the change of mechanism. If there are untested properties to your opinion, please ping me and/or help me add those tests.

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