[Merge] ExecutionPayload preparation via PreparableDuty

[tbenr]

PR Description

introduces:

• new event onExecutionPayloadPreparationDue in ValidatorTimingChannel, called in TimeBasedEventAdapter
• new duty type PreparableDuty

The idea is to run execution payload preparation on:

• slotTime + 4s at one slot prior to each slot where we have a Block Production duty.
• on each reorg event (late block) occurring on a slot prior to a slot where we have a Block Production duty

TODO: unit tests

Fixed Issue(s)

related to #4504

Documentation

• I thought about documentation and added the documentation label to this PR if updates are required.

Changelog

• I thought about adding a changelog entry, and added one if I deemed necessary.

[ajsutton]

Few things:

1. I don't think this lines up with the way that the standard REST API is moving. The VC will simply report which validators it's running to the beacon node and then the beacon node is reponsible for calling prepareExecutionPayload at the right time if any of those validators are scheduled to propose. So I don't think we'll need this even in the VC at all - it will wind up in the beacon node. Addition of prepare_beacon_proposer endpoint. ethereum/beacon-APIs#178 is the PR to make the REST API changes and Calling engine_preparePayload in advance sigp/lighthouse#2715 has a bigger write up of it.
2. We want to call prepareExecutionPayload early if we already have the block for the slot (same as we attest early if we receive the block). That gives the execution engine the maximum amount of time possible to prepare the payload. If we don't have the block by 4s into the slot then we'd call it anyway.
3. We won't get a re-org event if the block is received late - Teku doesn't consider switching from an empty slot to a filled one a reorg. So we'd need to trigger a new call on any canonical block being received or on a re-org.