Fixes various problems revealed by Windows CI runs

[Klaim]

This PR fixes various issues which are either specific to Windows (python path issue) or timing issues randomly revealed by Windows tests runs:

1. the python debugger object was not destroyed while the GIL was acquired, leading to UB which was more visible on Windows as random access violations (segfaults);
2. variations in xpython process startup timing, more pronounced on Windows, lead to random tests failing because of zmq's heartbeat check failing and throwing an exception, leading to the test executable crash;
3. std::system was used in tests to launch the xpython project and using & to run it in parallel and continue, but this only works with bash and on Windows the & is not interpreted the same way by cmd, resulting to tests waiting for xpython to complete on Windows and ultimately leading to timeouts;
4. the python executable path deduction algorithm was incorrect when I tried locally on Windows (it was looking for the exe in the myenv/Library/ directory instead of myenv/) - note however that I couldnt reproduce that specific problem on the CI which uses explicit env variable to specify this path, it's only visible when there is no such specification this is not considered here as the issue is actually the user not specifying or wrongly specifying PYTHONHOME;
5. issue 4 or any failed handling of script execution (zmq absorbing uncaught exceptions in that case) could result in zombie xpython running without me noticing while re-running the test, which lead to other errors.

Issues 2, 3, 5 are fixed in this PR by using boost.process (only as a dependency of the test executable) to

• properly launch xpython subprocess in a cross-platform way and in parallel,
• read xpython's I/O to wait for it to be ready after launch before proceeding to any testing,
• and automatically terminate that sub-process once done with testing (through RAII).

Issue 5 is also fixed in this PR by tracking the stilll-running xpython sub-processes until after main() is finished and if some are still running (usually because of errors in xpython) will terminate the remaining sub-process. This works with aborts (resulting from uncaught exceptions or not) but not with quick-exits.

Note that only 4 is specific to Windows, the others could theorically happen on other platforms (speed/timing and UB differences) and the fixes reflect that.

Most of the changes here were first experimented and confirmed working through #685, #686, and experimented with the incoming async changes in #697.

[SylvainCorlay]

Maybe use the macro for acquiring the GIL and calling decref on the object?

[Klaim]

I looked for such macro but couldnt find it in pybind11's doc, if you have the name at hand I can try it.

Meanwhile I tried to use ref-decrement instead of moving-locally-and-destroy as it does seem to make more sense. It seems to work as expected locally at least.

[SylvainCorlay]

Thanks