Structured concurrency: TaskHandle

[Attila Kelemen]

To summarize my (current) opinion: The more I think about it, the more
I believe that Rémi's initial assessment was correct, and STS should
not concern itself with classifying results into canceled and failed
states. This is because what counts as canceled is complicated, and
people might want different things in different contexts. Also this
would align with Alan's comment that STS is supposed to be something
simple. Which is probably the correct call, no matter how I would like
to dream about the awesome API solving all the issues. That said, to
be simple STS should not try to make "clever" decisions to classify
results, but rather tell me what happened as it did (so people can
build more opinionated APIs on top of it). What I think should be
recorded:

1. The result of a task state should either be Failed(Throwable) or
Success(result). Not even RUNNING state is necessary, because what can
I really do with it in the current API, if I can't wait for tasks
separately?

2. STS should not be clever, and the result should just mean what the
given task did. If it returns normally, then it is "Success" as far as
STS can tell (no matter the `shutdown` call).

3. It should record the fact that the task was completely skipped.
This could be very good to know info, because then I can efficiently
argue what changed (nothing due to this task).

4. It should record the fact that shutdown might have been called
prior to the completion of the task.

5. Unrelated to the above, but `TaskState.task()` should be removed.
It is dangerous, because it retains objects associated with the task
object, and provides very little use. It is also not useful for
identifying the task. It is also dangerous, because you very commonly
want to wrap task objects. For example, you might want to add a
version of fork which runs a `Runnable`, in which case the `Runnable`
will be wrapped.