Add randao to execution payload

[mkalinin]

Adds the most recent randao_mix into execution payload.
This PR is a follow up to the corresponding discussion that took place in Merge Implementers' Call 5.

The value of new randao field in ExecutionPayload must be assigned to difficulty field of derived ExecutionBlock. And further randao value is exposed by the DIFFICULTY opcode in the EVM. This way allows to preserve randomness property of the value returned by this opcode. Potentially, DIFFICULTY opcode will be renamed to RANDAO and is one of the post-Merge cleanups.

There two reasons why randao should be an explicit part of the payload:
- ExecutionPayload is the only input required to build corresponding ExecutionBlock
- further compatibility with stateless execution

UPD
The main idea of this particular solution is to exclude EVM changes from the Merge scope. An implementation where randao value is passed alongside with the payload and utilized by EVM context directly without requirement of being a part of ExecutionBlock could be done after the Merge within other EVM changes.

Should be rebased after #2472 gets merged

[djrtwo]

nice! a bit confused about Bytes32() in the helpers for randao reveal but otherwise, looking good

[JustinDrake]

suggested polishing:

[djrtwo]

I'm okay with the suggested cleanups.

Although it is an important design goal for execution layer to be parallelizable, I don't think the added param moves the needle too much on making that clear to the reader. I would suggest noting the parallelizability in the header comment (or pre-function text) of process_execution_payload and make it clear there if there are any important considerations.

[mkalinin]

Thanks everyone for your inputs! I've accepted suggested polishing with related comment about randao_mix dependency in process_execution_payload and its impact on ability to process the payload in parallel. I am ok with this change now and it can be merged once approved.