Add new variant of `persisted_validation_data` runtime API for elastic scaling

[sandreim]

We need to introduce a new RuntimeAPI that accounts for a parachain having multiple cores assigned. In it's current form it's signature looks like this:
fn persisted_validation_data(para_id: ParaId, assumption: OccupiedCoreAssumption)

But, after merging #3479 the semantics of the assumption are changed and refer to a group of cores rather than a single core. Currently, the way the assumption works in practice is that collators can be optimistic around candidates pending availability on certain cores. But with elastic scaling parachains the runtime enacts the full chain of pending availability candidates rather than individual ones.

For example, if the following chained candidates A,B,C are pending availability at RCB N. We delay enacting B and C even if they became available at N+1 until A has become available.

So collators need to bet on the length of the chain that gets included in the next block, such that they can properly build the next candidates and avoiding doing useless work.

[alindima]

I don't think this is needed because I modified the runtime API implementation to force enact all occupied cores of a para for OccupiedCoreAssumption::Included

So collators need to bet on the length of the chain that gets included in the next block, such that they can properly build the next candidates and avoiding doing useless work.

I think in practice collators would always be optimistic that their backed candidates will get included.

Hence I think we can close this issue unless @skunert envisions a collator that would do such betting on which backed candidates will get included or timed out. I think an all or nothing approach as we have right now is enough

[skunert]

betting on which backed candidates will get included or timed out

I agree, from parachain perspective candidate timeouts are nothing we can influence so we need to be always optimistic about it.