runtime refactoring: remove the claim queue from the scheduler

[alindima]

If we remove the TTL, the claim queue in the scheduler pallet does not make much sense any more.

The claim queue remains merely an intermediate buffer to the coretime assigner pallet, which is populated with up to scheduling_lookahead claims.
It also complicates things as assignments need to be pushed back to the assigner on session changes (if the core count decreases).

Backwards compatibility with the claim queue runtime API will be maintainted. The logic will be modified to peek up to scheduling_lookahead positions in the coretime assigner.

This greatly simplifies the scheduler pallet and helps with the separation of concerns.

As @eskimor pointed out, it also has a nice side effect that the latency between ordering an on-demand core and being able to use the core will decrease. This is because the on-demand order extrinsic reaches the on-demand assigner but not the claim queue (the claim queue is filled during inherent data processing, which happens before extrinsics). There was therefore a latency of at least one block between when the order is fulfilled and when the assignment could be used. If we modify the runtime API to look directly into the assigner, the parachain could utilise this claim right at the next block (granted that the core is available).

[alindima]

Another idea for refactoring the scheduler: #5461 (comment)