[Feature Request] Support Nexus operation cancellation types

[pdoerner]

Describe the solution you'd like

We would like to expose cancellation types for Nexus operations to give users control over what happens to their Nexus operations when the parent context is cancelled. This behavior should follow the pattern set by child workflows. There should be 4 new cancellation types where are specified as part of the input options when starting an operation.

1. ABANDON -> Do not send a RequestCancelNexusOperation command
2. TRY_CANCEL -> Send a RequestCancelNexusOperation command and immediately report cancellation to the caller without waiting for confirmation that the operation was cancelled.
3. WAIT_REQUESTED -> Request cancellation of the operation and wait for confirmation that the cancel request was received by the operation handler.
4. WAIT_COMPLETED -> Request cancellation of the operation and wait for the operation to complete. It may or may not complete as cancelled. This is the current behavior and therefore should be the default for backwards compatibility.

To support WAIT_REQUESTED, two new history events were added in temporalio/api#564 for NexusOperationCancelRequestCompleted and NexusOperationCancelRequestFailed. When either of these events are seen, that means that the cancel request was successfully delivered to the operation handler and futures for operations started with WAIT_REQUESTED can be unblocked.

[dandavison]

We started work on sdk-core support for Nexus cancellation types in #927. However, we have not yet made WAIT_REQUESTED possible. To do so, we need to modify sdk-core to handle the two new event types NexusOperationCancelRequestCompleted and NexusOperationCancelRequestFailed. Currently, core does not work with --dynamic-config-value component.nexusoperations.recordCancelRequestCompletionEvents=true (NDE due to the unhandled events). But WAIT_REQUESTED requires that the server sends the new event.