This change is mostly a refactoring, except now, an arbitrary
`onCancelling` handler that's not a child will not add itself in
a `synchronized` block. Instead, only the root cause is read under
a lock.

Before this change, when children were prohibited from adding
themselves to the list, cancellation handlers were also prohibited
from doing so. This was plain incorrect, because a list that's
closed for new children could still get cancelled later, and also
because being closed for new children happened before advancing the
state to the final one.

`rootCause` is atomic anyway.

The failure went like this:
* A child arrives.
* In the meantime, the parent enters `tryMakeCompletingSlowPath`
  and remembers the current list of handlers, which is an empty
  or a single-element one.
* The parent updates the state to the finishing one.
* The child enters the list.
* The parent traverses *an old list*, the one from before the
  child arrived. It sees no children in the empty/single-element
  list and forgets about the child.

Why, then, was it that this worked before?

It was because there was a guarantee that no new children are going
to be registered if three conditions are true:
* The state of the `JobSupport` is a list,
* The root cause of the error is set to something,
* And the state is already "completing".

`tryMakeCompletingSlowPath` sets the state to completing, and
because it updates the state inside `synchronized`, there was a
guarantee that the child would see either the old state (and, if
it adds itself successfully, then `tryMakeCompletingSlowPath` will
retry) or the complete new one, with `isCompleting` and the error
set to something.

So, there could be no case when a child entered a *list*, but this
list was something different from what `tryMakeCompletingSlowPath`
stores in its state.

…List.kt

Co-authored-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>