Elastic scaling: Support new candidate descriptor

[axaysagathiya]

Epic summary

This issue is to support the new CandidateDescriptor

Why do we need a new candidate receipt

Prevent denial-of-service (DoS) attacks in elastic scaling by constraining candidate validity to a specific core.
Secure disputes by embedding the SessionIndex directly in the CandidateDescriptor, eliminating trust issues.

What do we need to update in struct

Remove

• Collator Signature and Collator ID because these fields provide no functional benefits on the relay chain and are unused in practice.

Introduce

• Version (byte) | 1 byte: Used to distinguish between different versions of CandidateDescriptor for backward compatibility
  Core Index (uint16) | 2 bytes: This identifies the core index where the candidate is committed. Tying the candidate to a specific core ensures elastic scaling security.
• Session Index (uint32) | 4 bytes: Encodes the session index to enhance dispute resolution security by making it deterministic and trustless.
• To make the backwards compatible, Reclaim the remaining space (reserved1: 25 bytes, reserved2: 64 bytes) and zero them for future extensibility.

Links to related tech. design or research documents

Switch node side to v2 candidate receipts: paritytech/polkadot-sdk#5679
polkadot node support for new candidate receipts: paritytech/polkadot-sdk#5047

Sub issues

Acceptance criteria

• raise design issue
• Prepare design doc
• raise/implement sub-issues