Rewrite the process monitor

[SeanTAllen]

Detect a child's exit from a native OS event instead of waiting for its output
pipes to close. Construction becomes a StartProcess factory that returns a
live ProcessMonitor or a ProcessError. This is the redesign worked out in
discussion #5769.

ProcessMonitor used "stdout and stderr both reached end-of-file" as the
signal that the child had exited. But a pipe reaches end-of-file only when
every process holding its write end has closed it, and the child is not always
the last one holding it: a grandchild that inherited stdout or stderr, or the
parent still holding the child's stdin, keeps the pipe open after the child is
gone. So ProcessMonitor reported the exit late, or not at all. That one wrong
assumption caused both #5764 and #5748.

Now the child's exit arrives as an OS event — a pidfd on Linux, EVFILT_PROC
on kqueue, and a waitable process handle on Windows — and that event is the
only signal that the child has exited. A pipe reaching end-of-file is now just
a reason to stop reading that pipe. Two related bugs go with the change: the
kill-after-reap guard is now structural (#5765), and a start that fails no
longer leaks its pipes (#5766).

Closes #5764, #5748, #5765, #5766. Design: #5769.

What changed for callers

Starting a process now returns a result. Where you wrote:

let pm = ProcessMonitor(sp_auth, bp_auth, consume notifier, path, args, vars)

you now write:

match StartProcess(sp_auth, bp_auth, consume notifier, path, args, vars)
| let pm: ProcessMonitor => // a live child is running
| let err: ProcessError  => // never started; err says why
end

Failures that used to arrive asynchronously through ProcessNotify.failed — no
execute permission, a missing executable, and now a Linux kernel too old for
pidfd_open — are returned synchronously by StartProcess, and no monitor is
created for them. The ExecveError that meant two things (a missing file, and
execve failing in the child) is split: the missing-file precondition is now
ExecutableNotFound.