Allow cancel operation to maintain scope termination reachability

[mxgrey]

Currently scopes get automatically cancelled the instant their terminate operation becomes unreachable. This can be inconvenient in situations where the users wants the workflow to remain active for some period of time running services that may have some side effects before ultimately allowing the workflow to cancel.

A workaround that can already be used is to put those additional services into a cleanup workflow that will be run after the workflow gets cancelled, but this takes extra thought from the user and doesn't necessarily provide a clear or intuitive expression of what the user wants to have happen.

Instead we could consider allowing the scope termination to still be considered "reachable" if any cancellation operation is still reachable. This way the user can put the cancellation operation at the end of their chain of side-effect operations to ensure that those operations will run instead of moving those operations into a cleanup workflow.

There is both a semantic and a practical difference between the terminate operation and the proposed cancellation operation:

• Semantic: The cancellation operation will explicitly tell the caller that the workflow was cancelled instead of exiting normally. This may be relevant information to convey to the caller.
• Practical: A workflow's terminate operation may require a certain message type that the user is expecting to receive as the response of the workflow. The cancellation operation would instead allow a trigger () to be passed to it (or any stringifiable message), so there is no constraint on what kind of service connects to it since every message can be remapped to a trigger message.