common/CScriptObj: use posix_spawn() instead of vfork()/execlp()

[MaxKellermann]

Using vfork() directly is extremely fragile, and posix_spawn() is easier to use. This implements a TODO comment.

[cbnolok]

Thanks for the PR! Did you manage to test it?

[MaxKellermann]

No, I admit I havn't tested it because I don't know how to call it. I changed this only because Sphere wouldn't compile with vfork():

FAILED: CMakeFiles/spheresvr_release.dir/src/common/CScriptObj.cpp.o 
[...]
In file included from Debug/CMakeFiles/spheresvr_release.dir/cmake_pch.hxx:9,
                 from <command-line>:
src/common/CScriptObj.cpp: In member function ‘virtual bool CScriptObj::r_WriteVal(lpctstr, CSString&, CTextConsole*, bool, bool)’:
src/common/CScriptObj.cpp:427:9: error: variable ‘inLocalBlock’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered]
  427 |         EXC_TRY("WriteVal-Ref");
      |         ^~~~~~~
src/common/CScriptObj.cpp:427:9: error: variable ‘inLocalBlockCnt’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered]
  427 |         EXC_TRY("WriteVal-Ref");
      |         ^~~~~~~
cc1plus: all warnings being treated as errors

vfork() is indeed a minefield and nearly impossible to use safely without resorting to assembly, because you never know what the C++ compiler generates. But what Sphere does here is illegal, not even counting for compiler quirks. I wonder how this could ever have worked at all.
So something had to be done.

I thought the function was buggy because it left zombie processes, but then I saw the SIGCHLD handler which calls waitpid() from within the signal handler. I didn't know this was legal (maybe it isn't). But this can obviously break the waitpid() call in CScriptObj (maybe not if Sphere takes care to adjust the signal block mask before calling CScriptObj, but I guess it does not).
So the function is indeed buggy after all, but differently buggy than I thought.