Bump consensus runtime spec version

[NingLin-P]

This PR bumps the consensus runtime spec version from 5 to 6 as preparation for the upcoming consensus runtime upgrade in gemini-3h. Also, this PR removes the #[codec(skip)] for the maybe_domain_sudo_call_proof field in FP.

Code contributor checklist:

• I have read, understood and followed contributing guide

[nazar-pc]

I'm not sure how is this supposed to work on the client side, can you explain?

[NingLin-P]

FP is expected to be rare in the network and the client only constructs/submits FP through the runtime time (not extracting FP from the runtime state), so the worst situation is the invalid extrinsic root FP triggered after the runtime upgrade and domain node didn't include this change will crash due to failed to submit FP, it can be fixed by upgrade the client to a newer release or restart after FP is submitted by other nodes.

Generally, I think this is okay for gemini-3h, but for mainnet we need to resolve #2942 completely before changing any shared data structure.

Also, we do need another client release to include this change and #2947, the domain node that is on jul-26 needs to upgrade to this new release otherwise they may crash after the runtime upgrade due to #2947.

[nazar-pc]

I do not think I fully understand how this is going to work. We already had fraud proofs on 3h, changing data structure indicates decoding will fail for either old or future fraud proofs unless client is somehow prepared to deal with this. Unless I misunderstand what this does and how it works.

[NingLin-P]

The client doesn't decode the FP, it only constructs, encodes, and submits FP through runtime API, so the domain node only crashes if:

• FP is triggered after the runtime upgrade
• And it didn't upgrade to the client that included this change

This is different from ER, where the domain node will extract and decode ER in every consensus block (from genesis to the best block) so any change to ER will crash the domain node.