[RFC] Engine API: is payload statuses worth reworking?

Currently, Engine API has the following payload statuses:
* `VALID` - payload is valid, requires full validation
* `INVALID` - payload is invalid, doesn't require full validation (block header values might be invalid)
* `INVALID_BLOCK_HASH` - recently became equal to `INVALID`, see https://github.com/ethereum/execution-apis/issues/270
* `ACCEPTED` - a side chain payload hasn't been validated, but ancestors of this payload are locally available
* `SYNCING` - parent block of a payload is unknown; or equals to `ACCEPTED` if EL doesn't support `ACCEPTED`

The problem of utilizing `ACCEPTED` is that it does not preclude EL from pulling pieces of state from the network in order to obtain a parent state of a payload in question.

Apart from EL's implementation complexity, I am curious if we had a clear status meaning "I can compute parent state *locally*" would CL make use of it? If a state can be locally computed it should take less time and preclude the possibility of DA issues.

If yes then we could have the following statuses (names are picked for clarity not for brevity, so we can leave the same names):
* `VALID`
* `INVALID`
* `MISSING_DATA` - parent block is unknown or parent state can't be locally computed, reorg to this block implies `SYNCING`
* `HAS_REQUIRED_DATA (ACCEPTED)` - parent state is unknown but is locally computable
* `VALIDATING (SYNCING)` - EL is either computing a parent state or pulling data from the network and will validate a payload once parent state is obtained

ELs are free to choose to not `HAS_REQUIRED_DATA ` and always response `MISSING_DATA` instead. But if EL do support the former, CL may optimise for such a support.

This proposal changes a set of statuses for Engine API methods in the following way:
* `newPayload: VALID | INVALID | MISSING_DATA | HAS_REQUIRED_DATA (ACCEPTED)`
* `forkchoiceUpdated: VALID | INVALID | VALIDATING (SYNCING)`

**UPD**
These changes (if we decide to take them) aren't considered to be incorporated before the Merge

**UPD 2**
We might even want to split `VALIDATING` into two separate statuses: `SYNCING` and `EXECUTING`. The latter would mean that the execution is in progress but all required data are locally available. This would allow CL to avoid remembering whether the payload is either `MISSING_DATA` or `HAS_REQUIRED_DATA`, and solely rely on `fcU` status to understand what EL is doing.