handle killed-by-signal process state properly

[Guest0x0]

On Unix-like systems, when a process is killed by a signal, the process would have a special return status, differing from any normal exit code. Previously:

• when a process running async fn main is cancelled gracefully by signal, it return 128 + signal_number normally. This is the convention used by bash/zsh, but ambiguous and not faithful (the process is actually killed by signal)
• when a child process spawned by @process.run etc. is killed by signal, the returned exit status is simply corrupted

This PR fixes these two problems:

• when async fn main is gracefully cancelled via a signal, the program will kill itself with the same signal after finishing all the cleanup, creating an actual killed-by-signal exit status
  • on Windows, when the process is terminated gracefully via a console control event, async fn main will exit with CONTROL_C_EXIT_STATUS following Windows convention.
• when a child process spawned by @process API is killed by a signal, the returned exit status of run, .wait_pid and Process::wait would be -signal_number. Using negative number is unambiguous on Unix-like systems and can avoid breaking existing API. This is also the convention used by Python's subprocess API

[coveralls]

Coverage Report for CI Build 895

Coverage decreased (-0.04%) to 76.885%

Details

• Coverage decreased (-0.04%) from the base build.
• Patch coverage: No coverable lines changed in this PR.
• 2 coverage regressions across 2 files.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

2 previously-covered lines in 2 files lost coverage.

File	Lines Losing Coverage	Coverage
src/internal/event_loop/network.mbt	1	75.0%
src/socket/happy_eyeball.mbt	1	81.08%

---

Coverage Stats

Relevant Lines:	4867
Covered Lines:	3742
Line Coverage:	76.89%
Coverage Strength:	12184.94 hits per line

---

💛 - Coveralls