UpdateAdmitted event processing

[dandavison]

Draft PR, for review: I've tested this manually using a Python workflow that sends updates and performs a reset, but I have not yet added sdk-core tests

This PR adds handling for the new WorkflowExecutionUpdateAdmitted event ("UAdm") that the server is going to start sending for reapplied updates (i.e. after reset / conflict resolution).

If the server does request an update by sending the new event type, then:

1. It will not send a protocol message.
2. The event will have the update request payload.
3. If the update is accepted, then the server will write a WorkflowExecutionUpdateAccepted event ("UAcc") without the request payload.

Implementation notes

• During non-replay, the server may send UAdm: in this case we create the corresponding protocol message so that the validator and handler are executed.

• If we encounter a UAdm event during replay then we also create the protocol message, but hold it to one side until we find out whether the update was accepted or not.

• When handling a UAcc event during replay we first look to see if we have a UAdm protocol message held to one side for us; if we do then we use that, since that has the request payload and in this situation the UAcc event will not have the payload.

• If an update has no UAdm events then the new implementation reduces to the previous implementation: i.e. we respond to protocol messages received during non-replay, and we respond to UAcc during replay by creating the protocol message.

How this was tested

This samples-python script against this WIP server branch