task: elaborate safety comments in task deallocation

[Darksonn]

I came across rust-lang/rust#55005 and learned of the following special exception:

For both &T without UnsafeCell<_> and &mut T, you must not deallocate the data until the reference expires. As a special exception, given an &T, any part of it that is inside an UnsafeCell<_> may be deallocated during the lifetime of the reference, after the last time the reference is used (dereferenced or reborrowed). Since you cannot deallocate a part of what a reference points to, this means the memory an &T points to can be deallocted only if every part of it (including padding) is inside an UnsafeCell.

source

However, I noticed that our calls to decrement the ref-count are currently written like this:

self.header().state.transition_to_notified_by_val()

The reference returned by header() is alive until the expression ends, which is after we have dropped the ref-count, so the &Header might still exist after another thread has deallocated the task. This PR changes it so only a &State could be alive when another thread deallocates the task, which the standard library explicitly says is ok as its entire contents are wrapped in UnsafeCell.

[Darksonn]

Somehow miri failed on this with the following error:

error: Undefined Behavior: not granting access to tag <3613730> because that would remove [Unique for <3613708>] which is protected because it is an argument of call 1030169
   --> tokio/src/runtime/scheduler/multi_thread/queue.rs:386:28
    |
386 |             let src_tail = self.0.tail.load(Acquire);
    |                            ^^^^^^^^^^^^^^^^^^^^^^^^^ not granting access to tag <3613730> because that would remove [Unique for <3613708>] which is protected because it is an argument of call 1030169
    |
    = help: this indicates a potential bug in the program: it performed an invalid operation, but the Stacked Borrows rules it violated are still experimental
    = help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
help: <3613730> was created by a SharedReadWrite retag at offsets [0x20..0x24]
   --> tokio/src/runtime/scheduler/multi_thread/queue.rs:386:28
    |
386 |             let src_tail = self.0.tail.load(Acquire);
    |                            ^^^^^^^^^^^^^^^^^^^^^^^^^
help: <3613708> is this argument
   --> tokio/src/loom/std/atomic_u32.rs:26:10
    |
26  |         *(*self.inner.get()).get_mut()
    |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    = note: BACKTRACE:
    = note: inside `runtime::scheduler::multi_thread::queue::Steal::<runtime::blocking::schedule::NoopSchedule>::steal_into2` at tokio/src/runtime/scheduler/multi_thread/queue.rs:386:28
note: inside `runtime::scheduler::multi_thread::queue::Steal::<runtime::blocking::schedule::NoopSchedule>::steal_into` at tokio/src/runtime/scheduler/multi_thread/queue.rs:348:21
   --> tokio/src/runtime/scheduler/multi_thread/queue.rs:348:21
    |
348 |         let mut n = self.steal_into2(dst, dst_tail);
    |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: inside closure at tokio/src/runtime/tests/queue.rs:132:20
   --> tokio/src/runtime/tests/queue.rs:132:20
    |
132 |                 if steal.steal_into(&mut local, &mut metrics).is_some() {
    |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

[Darksonn]

The miri failure is unrelated, and will be fixed by #5175. It is a coincidence that it was discovered on a PR related to miri.