Remove consensus operation branching conditions

Context

Historically, endorsements were branched on the block they were supposed to endorse in order to save space. In Tenderbake, this branching is not necessary anymore but we kept this invariant modifying it a bit by requesting endorsements to be anchored on the endorsed block's predecessor. This was motivated by the fact that sometimes endorsements would be ignored and dropped by the mempool (shell-side) because they were referring to block currently being validated and not yet part of the chain: therefore, not satisfying the "live_blocks" check.

Currently, and it's exacerbated with the pipelining, we still have this issue. Consider this situation on a node:

G -- A (--B)
  \- A'

1. the block A arrives and is applied at round 0, the consensus is reached but B is not yet proposed;
2. the block A' arrives and is applied at round 1, the head switches, the mempool flushes;
3. the block B arrives and is validated but not yet applied but the pipelined baker start preendorsing and injects its preendorsement in the node while the mempool's context is still on A'.

In this situation, injecting the operation (without force) the mempool will simply drop early preendorsements on B.

The solution implemented in this MR consists of removing the branch requirement for endorsements and make the baker anchor those on a finalized block (i.e., the predecessor's predecessor of the endorsed block, G instead of A in the example). This way, a synchronized node's mempool will always be able to consider early (pre)endorsements.

However, we lose the canonicity property ensuring that only one consensus operation representation was possible for each operation which was actually false due to non-determinist signatures. Nonetheless, we still want to prevent spamming as much as we can: therefore, we make it possible to denounce two equivalent endorsements (i.e., same payload, level, round) anchored on two different branches. This doesn't change much the initial condition: we forbid participants to double sign (pre)endorsements on a same level/round.

Manually testing the MR

CI

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