Follow-on from #13879, which has been sporadically failing in Jenkins.

There are two kinds of failure which have been showing up:

1. The test fails because of a Sys_error exception reporting "tmp.txt: Permission denied"
2. The test fails because an fd which was expected to be closed appears to be open

I've investigated this further (in large part, because one of the bug-fixes in Relocatable OCaml made both these issues much more reproducible than they were before) and have determined:

1. Is caused by Windows Defender (or other file system filters). The issue is that the VM is under considerable load during a testsuite run. The various open handles to tmp.txt are closed by L6 in:
   

   ocaml/testsuite/tests/lib-unix/common/fdstatus_main.ml

   Lines 3 to 11 in 76ec239

   	let () =
   	for i = 2 to (Array.length Sys.argv) -1
   	do
   	process_and_close_fd (i - 1) Sys.argv.(i);
   	done;
   	(* For the execv version of the test, clean-up tmp.txt - for the
   	Unix.create_process version, this is done by cloexec.ml *)
   	if Sys.argv.(1) = "execv" then
   	Sys.remove "tmp.txt"

   
   but by the time we reach the Sys.remove on L11, Windows Defender has opened the file ready for "scanning", but not actually done it. As a result, the Sys.remove fails.
2. Amusingly, despite having switched to using CRT fds and Unix.execv in Restore lib-unix/common/cloexec.ml test on Windows #13879, we still end up seeing the same issue that caused the test to be disabled previously because of some missing code in caml_win32_CRT_fd_of_filedescr. The various mechanisms tested in cloexec.ml all correctly use SetHandleInformation or SECURITY_ATTRIBUTES, but when caml_win32_CRT_fd_of_filedescr converts them to CRT fds, we don't pass the O_NOINHERIT flag for close-on-exec handles. As a result all of the handles will be passed to the exec'd process - but the ones which are meant to be close-on-exec will just be invalid. However, what we are then sporadically seeing is that the Win32 handle value has been reused, so the CRT fd appears to be open (but it's in fact a different handle). This is what was being seen before when we were passing the Win32 handle values directly 🤦

Finally, while debugging this, I noted and have worked around an additional quirk of the way the exec family are implemented on Windows. Again, on an overloaded system, it's just possible that the exec'd program runs for quite some time, or even to completion, before the process which actually exec'd it (let's call it the "ancestor" rather than "parent", as it's not supposed to exist) has reached the _exit(0) call in the CRT. In this race condition, the handles may still be open when the Sys.remove is reached. That's obviously not a situation which can happen on a POSIX system, where the ancestor still running while the exec'd image is running is a major misimplementation!

This PR is therefore three commits:

1. On Windows only, cloexec.ml creates a file lock.txt (with O_CLOEXEC) and locks the entire file for reading and writing. Again, on Windows only, fdstatus_main.ml opens this lock.txt and also attempts to lock the file for reading and writing. This will only succeed once the "ancestor" has completely terminated - in other words, fdstatus_main.ml is then able to block until cloexec.ml has definitely terminated.
2. The second commit then deals with Windows Defender, et al. by opening tmp.txt with FILE_SHARE_DELETE and then adding an additional C stub which is used at the start of fdstatus_main.ml to open tmp.txt with FILE_FLAG_DELETE_ON_CLOSE. The Windows handle from this is then intentionally leaked - the point is that the handle will be automatically closed by Windows when the process exits and when Windows Defender has finally scanned it, the kernel will dutifully delete the file for us. Enough processes get held open in the process group while this happens that ocamltest waits around as normal for the test to conclude. This is a well-known problem on Windows, but this a less-common solution to it. The more common approach is to spin for up to a few seconds, retrying the deletion every 100ms or so. The solution I propose here is technically neater - the file is temporary, and we're using an (old and) actual Windows technology for dealing with the removal of temporary files, but also the value of the timeout we'd need for the spin is hard to determine - in one run on precheck, the delay is 10 seconds...!
3. The final commit uses GetHandleInformation to determine if the Win32 handle has been marked as inheritable. If it is not, then we pass O_NOINHERIT to _open_osf_handle, which causes the CRT fd book-keeping to be corrected.

Note that while the fix to caml_win32_CRT_fd_of_filedescr is a bug-fix, it is not as critical a bug-fix as it might look on first glance. Handles marked as close-on-exec were not being passed to any exec'd processes - the issue is that the Win32 handle values were being passed in fds, but the descriptors fail on first use. This combined slightly unfortunately in the cloexec.ml test with the fact that Windows uses HANDLE values for multiple things and meant that the fdstatus_main.ml might re-use the value of a HANDLE with the result that an fd appeared open - but it would not be a handle to the same thing as in cloexec.ml (i.e. the bug is book-keeping/correctness and not security). That said, Jenkins is relatively frequently suffering from this, so it'd be good to fix the test (again)...