fix: 🚑 Re-initialise BSPs' challenge cycle when changing stake

[ffarall]

In this PR:

1. Keep track of last tick proven as well as next to prove.
   1. This fixes a bug where Providers would always be slashed in the cycle they change their stake.
   2. LastTickProviderSubmittedAProofFor storage element in the Proofs Dealer pallet is replaced with ProviderToProofSubmissionRecord which holds a new struct ProofSubmissionRecord, with both the last tick proven and the next to prove.
   3. This comes with the added benefit of an ~5x reduction in proof_size weight for the submit_proof function, presumably because there is no more need to check a Provider's stake.
   4. Added test cases both for increasing and decreasing the Provider's stake.
2. Fix bug where checkpoint challenges were required to be submitted both when the last checkpoint tick was equal to the last tick proven, and when the last checkpoint tick was equal to the current challenge tick to prove. In essence, the condition was set so that a provider should submit proofs for the checkpoint challenges if:

   last_tick_proven <= checkpoint_tick <= challenge_tick_to_prove
   

   That meant that if checkpoint_tick was equal to challenge_tick_to_prove, the Provider would have to submit proofs for the checkpoint challenges in that proof and also in the next one, where last_tick_proven would be equal to checkpoint_tick. Consequently this was changed so that the checkpoint challenges are only required when checkpoint_tick is equal to challenge_tick_to_prove:

   last_tick_proven < checkpoint_tick <= challenge_tick_to_prove
   

   1. Add to existing test checks for this condition. In essence a test with checkpoint challenges, after a successful proof submission of the first proof (including the checkpoint challenges), the second submission doesn't include them. In the first submission, checkpoint_tick == challenge_tick_to_prove, while in the second submission checkpoint_tick == last_tick_proven.
3. Now checkpoint challenges accrue in slashing if Provider continues to not submit proofs successively.
4. Added get_next_tick_to_submit_proof_for runtime API to fetch the next tick to prove for a given Provider. Now it's not necessarily the last tick proven + challenge priod.

[TDemeco]

Looks good 💯