Clarify ExitStatusExt documentation

[schneems]

Fix struct links

There are several structs (ExitStatus and ExitStatusError) that could be linked, but aren't. Fixed. All links show their struct now instead of previously some showed process::ExitStatus when rendered.

Add wait links

The docs distinguish wait as code, but do not link to what wait they're referring to. As this is Unix extension documentation, adding a link to the POSIX standard for wait. Showing a construction of an ExitStatus for both a signal and an exit code helps to highlight and internalize what wait status, not an exit status means.

Example for from_raw

Current documentation calls out "The value should be a wait status, not an exit status." but it's unclear what exactly that means without a reference or an example. I added a doctest that shows you need to shift by 8 to get the desired result and annotated it with information about how that's derived based on the linked wait documentation.

Example to ExitStatus::signal

Called out that a signaled process does not also produce an exit code. Added an example. Called out that just because a process reports that it was not terminated via a signal doesn't mean it never got one (it could be handled). Also added a note correlating shell behavior to exit codes:

GNU Bash manual: https://web.archive.org/web/20260625050034/https://www.gnu.org/software/bash/manual/bash.html#Exit-Status-1

[...] a fatal signal whose number is N, Bash uses the value 128+N as the exit status.

FreeBSD bash(1) man page: https://man.freebsd.org/bash/1

The return value [...] 128+n if the command is terminated by signal n.

Panic scope on from_raw

This change is based on preference/experience:

When I originally read this documentation, it was because I clicked through Output -> ExitStatus. While the text "Creates a new ExitStatus or ExitStatusError" is present at the top, I didn't internalize what that meant exactly. Therefore, when I got to the panic section, I was mildly confused.

This edit makes the behavior more explicitly attached to the type. While the original format had all of the same information available, it was left for the reader to bridge that "making an ExitStatusError" is referring to ExitStatus::from_raw as that's the only constructor (for now).

Making this bridge more explicit also future-proofs us for future constructors (if they're ever added) that may or may not panic. While the context of the panic documentation is directly attached to from_raw, it's slightly (pedantically) more correct to not imply that ANY way of creating an ExitStatusErrorfrom awaitof0` will panic (a different constructor could perhaps return an option instead).

Technically, the syntax isn't correct, as it should be <ExitStatusError as ExitStatusExt>::from_raw, but I think this conveys intent without being overly verbose.

[rustbot]

r? @Darksonn

rustbot has assigned @Darksonn.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @ChrisDenton, libs
• @ChrisDenton, libs expanded to 13 candidates
• Random selection from 6 candidates