Functions that may panic can be annotated with #[track_caller] so that
in the event of a panic, the function where the user called the
panicking function is shown instead of the file and line within Tokio
source.

This change adds #[track_caller] to all the non-unstable public net APIs
in the main tokio crate where the documentation describes how the
function may panic due to incorrect context or inputs.  Not all panic
cases can have #[track_caller] applied fully as the callstack passes
through a closure which isn't yet supported by the annotation (e.g. net
functions called from outside a tokio runtime).

Additionally, the documentation was updated to indicate additional cases
in which the public net functions may panic (the same as the io
functions).

Tests are included to cover each potentially panicking function.

Refs: tokio-rs#4413

Without a windows machine to test on, I had to add the test before
adding track_caller to ensure that it failed first. This commit adds the
change that should make the test pass (and also fixes the test name).

Functions that may panic can be annotated with `#[track_caller]` so that
in the event of a panic, the function where the user called the
panicking function is shown instead of the file and line within Tokio
source.

This change adds `#[track_caller]` to all the public APIs in the sync
module of the tokio crate where the documentation describes how the
function may panic due to incorrect context or inputs.

In cases where `#[track_caller]` does not work, it has been left out.
For example, it currently does not work on async functions, blocks, or
closures. So any call stack that passes through one of these before
reaching the actual panic is not able to show the calling site outside
of tokio as the panic location.

The following functions have call stacks that pass through closures:
* `sync::watch::Sender::send_modify`
* `sync::watch::Sender::send_if_modified`

Additionally, in the above functions it is a panic inside the supplied
closure which causes the function to panic, and so showing the location
of the panic itself is desirable.

The following functions are async:
* `sync::mpsc::bounded::Sender::send_timeout`

Tests are included to cover each potentially panicking function.

Refs: tokio-rs#4413

Modified the description of situations in which some functions can panic
to align with reviewer suggestions (at least that's the intent).

Changed to remove duplicate cause statements based on suggestions during
the PR review.

Co-authored-by: Alice Ryhl <aliceryhl@google.com>

…ler-net

Catch unwind isn't supported, so these tests won't work.