Engine API: refine message ordering section

[mkalinin]

Refines the Message ordering section of the Engine API.

The previous version of the spec had the following overlooks:

• CL could flip two forkchoiceUpdated messages before the IDs were assigned which could result in inconsistency of the head of the chain between the layers
• The restrictions on EL side were too strong. EL couldn't process two different messages in parallel which e.g. locks the client until executePayload processing is finished

Proposed changes:

• CL: add the requirement to respect the order of occurrence of fork choice updated event
• EL: restrict enforcement of processing order to forkchoiceUpdated calls only

[lightclient]

1 nit, but generally LGTM.