bug#56002: src/process.c; make-process fails to clean up stderr process on early exit

[Tom Gillespie <tgbugs@gmail.com>]

If the primary subprocess created by make-process fails early then the
stderr process is not cleaned up and running kill-buffer on any stderr
buffer attached to the stderr process will prompt the user.

Two early exits that can cause the issue are

1. in make-process if the command is not found
report_file_error ("Searching for program", program);

2. in create_process if vfork fails
report_file_errno (CHILD_SETUP_ERROR_DESC, Qnil, vfork_errno);

I'm sure there are other failure modes that would trigger the issue.

I know of at least two ways to trigger the behavior that correspond to
those two lines. One is to provide a :command that does not exist, the
other is to call an executable file with a format that Emacs does not
understand (e.g. a valid sh file that is missing a shebang line).

The following example shows the behavior for a non-existent command on
master at 556c304007fbea1a552c65529fa86c0a5637b27b. When running it
the program will stop at a prompt to kill the " rc stderr" buffer.
#+begin_src bash
read -r -d '' example <<'EOF'
(let ((stderr-buffer (generate-new-buffer " rc stderr")))
  (unwind-protect
      (let ((process
             (make-process
              :name "process that never actually starts"
              :stderr stderr-buffer
              :command '("i_fail_before_there_can_be_a_return_code")))))
    (kill-buffer stderr-buffer)))
EOF
src/emacs -Q -batch -eval "${example}"
#+end_src

One potential fix for the issue would be to decouple :noquery for the
primary process from the stderr process and make the stderr process
query_on_exit always false. The user has no knowledge that the stderr
process exists and also has no way to reference it from their code. If
they want :noquery nil behavior an advanced user could always
construct the stderr process themselves.

If that is done then it seems that the stderr process will
automatically clean itself up once the stderr buffer is killed. This
seems easier than trying to catch all early exit cases that would
leave the stderr process alive during an early exit.