Refactoring STM library for SNARK-friendliness

[jpraynaud]

Why

We need to refactor the STM library in order to make it SNARK-friendly. Following the definition of the architecture in #2763, we have defined an implementation plan and we want to address the refactoring part of the plan as a first step.

What

Implement the refactoring of the STM library for the concatenation proof.

How

• Step 1: Code re-organization
  • Create a commitment_scheme module and move merkle_tree in it
  • Create a signature_scheme module and move bls_multi_signature and schnorr_signature in it
  • Create a proof_system module and move concatenation_proof in it
  • Create a core or protocol module and move all the other modules in it
• Step 2: Code simplification
  • Move errors to their belonging modules
  • Remove the future_proof_system feature and replace it with the existing future_snark feature
  • Limit usage of <D: Digest> generics to merkle_tree module only (to be rechallenged)
  • Remove BasicVerifier implementation (and create a ticket for supporting this feature in a cleaner way in the future?) (to be rechallenged)
• Step 3: Implement SNARK-friendly changes for concatenation proof
  • Update the Merkle tree to support multiple leaves (for concatenation and following proof systems)
  • Update the key registration to support the new Merkle tree structure
  • Move responsibility of creating single signature artifacts to the concatenation proof system (in the proof_system module)