don't ever force fork() instead of forkfd()

this implements a suggestion made by a comment that got lost in
028ddf363: as explained in 97645478's commit message, we were forcing
use of fork() because we couldn't be sure that the code in a custom
setupChildProcess() did not rely on pthread_atfork() callbacks being
called.
however, that in turn was inconsistent with the default behavior, and
made customizing QProcess mutually exclusive with benefitting from
forkfd().
use the opportunity presented by changing the method of modifying child
process behavior to also change this.

this also amends 4e2f4670, as most of the now deleted comment in fact
related to the use of vfork semantics, which we don't do anymore.

[ChangeLog][Important Behavior Changes][QtCore][QProcess][Unix]
pthread_atfork() callbacks are consistently not invoked on reasonably
recent Linux and FreeBSD systems any more. This was already the case in
later Qt 5 releases, unless setupChildProcess() was overridden.

Change-Id: Icb239e4d2c705bf4665589469022a521267f7db5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>

src/corelib/io/qprocess_unix.cpp

@@ -450,17 +450,7 @@ void QProcessPrivate::startProcess()
         workingDirPtr = encodedWorkingDirectory.constData();
     }
 
-    // Select FFD_USE_FORK and FFD_VFORK_SEMANTICS based on whether there's
-    // user code running in the child process: if there is, we don't know what
-    // the user will want to do, so we err on the safe side and request an
-    // actual fork() (for example, the user could attempt to do some
-    // synchronization with the parent process). But if there isn't, then our
-    // code in execChild() is just a handful of dup2() and a chdir(), so it's
-    // safe with vfork semantics: suspend the parent execution until the child
-    // either execve()s or _exit()s.
     int ffdflags = FFD_CLOEXEC;
-    if (childProcessModifier)
-        ffdflags |= FFD_USE_FORK;
 
     // QTBUG-86285
 #if !QT_CONFIG(forkfd_pidfd)