Make Engine *V3s handle V3 requests only

[flcl42]

Requires #5596 to be merged

Implements ethereum/execution-apis #418

engine_getPayloadV3, engine_newPayloadV3 to handle Cancun payloads only.

Changes

• Make all fields required
• Return -38005: Unsupported fork, when V3 is called for a pre-Cancun payload

Types of changes

What types of changes does your code introduce?

• Bugfix (a non-breaking change that fixes an issue)
• New feature (a non-breaking change that adds functionality)
• Breaking change (a change that causes existing functionality not to work as expected)
• Optimization
• Refactoring
• Documentation update
• Build-related changes
• Other: Description

Testing

Requires testing

• Yes
• No

If yes, did you write tests?

• Yes
• No

Notes on testing

Requires Cancun fork

[marcindsobczak]

Looks correct!

[LukaszRozmej]

If we are going class hierarchy - which we now can and should! - let's use polymorphism. Previous design prevented us from doing that.

[LukaszRozmej]

Or maybe we shouldn't have class hierarchies in engine API parameter classes? This would make multi-dimensional extensions hard.
This spans 3 things now:

1. This PR
2. Eip 4788/beacon parent block root in evm #5476
3. Optimism extensions: https://github.com/NethermindEth/nethermind/blob/a44018a1d37cc4227a5ad88d95a16ead8bf2b931/src/Nethermind/Nethermind.Optimism/OptimismPayloadAttributes.cs
4. Potentially in future other orthogonal extensions to Engine API.

Now imagine that for now, Optimism doesn't need 4844 and #5476 fields, but at some point, it starts to need it. It will be hard to model the data classes correctly.

Options:

1. Duplicate the classes and check for optimism extensions with interfaces.
2. Design a more sophisticated method of composing extensions to requests.
3. Keep only one message type in main repo and just use null'able fields (what we do now)
4. Ignore for now :)

[LukaszRozmej]

comments + #5932