Allow better customization of cancellation behaviour

[mdickinson]

For the built-in task types, the current cancellation behaviour is that no further messages are received from the background task after cancellation. While this keeps the model simple, it's (a) rather brutal, and (b) not that well suited to cases where the background task being performed has side-effects.

Historical background: Traits Futures emerged from use-cases involving pushing calculations (pure functions, with a collection of inputs and a collection of computed outputs) to the background; in those cases, it make some sense for cancellation to mean "I'm no longer interested in this computation; don't tell me anything more about it".

However, the library is now being used for background tasks that are primarily there for their side-effects - e.g., uploading or downloading a file. In that situation, it would be useful to be able to:

• On cancellation, report the final status of the job (e.g., the number of files that were uploaded prior to cancellation, or the list of processed ids, or ...)
• Revert unwanted changes: e.g., roll back the completed portion of an incomplete transaction

The second use-case here should be easily supported by allowing the developer to catch the TaskCancelled exception; for the first, the ABANDONED message type could be adjusted to allow sending a value.

Related: #437. (See also #448.)

[mdickinson]

We should also look into making it easier to choose whether to continue to receive messages from the background task post-cancellation.

[mdickinson]

• Revert unwanted changes: e.g., roll back the completed portion of an incomplete transaction

This one's a little tricky, and subject to potential race conditions: the background task may not always get a chance to intercept the cancellation request, since the task might have completed (but with the completion message not having yet been received by the foreground) before the user cancels.