feat: ✨ add pallet-cr-randomness

[TDemeco]

This PR adds the pallet cr-randomness, which replaces the randomness pallet for the specific scenario of proof dealing.

• This pallet uses a commit-reveal scheme with all the Providers of the network, similar to how random challenges are distributed:
  • The period of submissions depends on the Provider's stake. Providers with a bigger stake have to submit commitments and reveal them more periodically than Providers with less stake.
  • Each reveal period has a tolerance. Providers must reveal their previous commitment and submit a new one during this tolerance period.
• The Providers get their randomness cycle initialised when they initially start storing one file and become active in the network. After this point, they have one period to submit a commitment (no need to submit a reveal, since they are new) for next cycle.
• Providers get their cycle stopped (by erasing them from the ActiveProviders mapping) when deleting their last file (which is equivalent of having a used capacity of 0). This makes it so they don't have to submit any more commitments and reveals and can't get slashed because of them.
• Providers can get slashed if they fail to reveal their previous commitment and submit a new one before their period + the tolerance has passed. If this happens, they will get notified by the ProviderMarkedAsSlashable event, which will hold their next deadline for which they have to submit only a commitment, not a reveal.
  • The pallet processes the Providers to mark as slashable in two separate hooks:
    • The on_poll hook, which gets executed every tick, saves to storage the list of Providers that were due a submission this tick but failed to comply.
    • The on_idle hook takes advantage of the remaining weight of blocks to get this stored list of Providers and mark each one of them as slashable, restarting their randomness cycle in the process.
• When a Provider reveals a previous seed, this seed is valid from the deadline block of the reveal onwards. That means that every block after the deadline one for that seed will have the seed mixed into its randomness. This makes it so randomness is unpredictable and gets better as time passes.
• Randomness from this pallet is used when distributing the random challenges each tick. TODO: this is not done yet because the client task that handles the commit-reveal cycle is not done, so integration tests would all fail because of unavailable randomness.

TODO:

• What should be a seed? And its commitment? I used hashes (H256) but @ffarall mentioned maybe using signatures.
• Should we limit the amount of Providers that have to submit commit-reveal per tick? This would allow us to limit the size of the vector of the providers to mark as slashable, but we have a natural way of trimming down that storage over time (in the on_idle hook)
• Benchmarking