Orphan background tasks to work around terminals being sensitive to unreaped processes

When a command like "long-running-command &" exits, the resulting SIGCHLD
is queued in the topic monitor. We do not process this signal immediately
but only after e.g. the next command has finished. Only then do we reap the
child process.

Some terminals, such as Terminal.app, refuse to close when there are unreaped
processes associated with the terminal -- as in, having the same session ID,
see setsid(3).

In future, we might want to reap proactively.

For now, apply an isolated workaround: instead of taking care of a child
process, double-fork to create an orphaned process. Since the orphan will
be reaped by PID 1, we can eventually close Terminal.app without it asking
for confirmation.

	/bin/sh -c '( "$@" ) >/dev/null 2>&1 &' -- cmd arg1 arg2

This fix confines the problem to the period during which a background process
is running. To complete the fix, we would need to call setsid to detach the
background process from a controlling terminal. That seems to be desirable
however macOS does provide a setsid utility.

	setsid cmd arg1 arg2 >/dev/null 2>&1

Fixes #11181

share/functions/__fish_config_interactive.fish

@@ -99,9 +99,8 @@ end" >$__fish_config_dir/config.fish
             set -l update_args -B $__fish_data_dir/tools/create_manpage_completions.py --manpath --cleanup-in $__fish_user_data_dir/generated_completions --cleanup-in $__fish_cache_dir/generated_completions
             if set -l python (__fish_anypython)
                 # Run python directly in the background and swallow all output
-                $python $update_args >/dev/null 2>&1 &
-                # Then disown the job so that it continues to run in case of an early exit (#6269)
-                disown >/dev/null 2>&1
+                # Orphan the job so that it continues to run in case of an early exit (#6269)
+                /bin/sh -c '( "$@" ) >/dev/null 2>&1 &' -- $python $update_args
             end
         end
     end