Fix some memory bugs in `runtime_events_consumer.c`

[eutro]

This PR fixes a few memory bugs surrounding runtime_events_loc in runtime_events_consumer.c, as mentioned in #13089, specifically in caml_runtime_events_create_cursor.

These bugs are:

• The code path for Runtime_events.create_cursor None (the pid < 0 branch in the C code) allocates runtime_events_loc but reassigns it, making the old pointer unreachable without deallocating it:

https://github.com/ocaml/ocaml/blob/4c6a3849022ba19c23fb1860095f65eb09da157c/otherlibs/runtime_events/runtime_events_consumer.c#L108-L124

• The function frees runtime_events_loc after it is introduced if and only if the function returns with an error.[^1] This is incorrect, both because:
  • in the pid < 0 code path, it shouldn't be freed at all, since caml_runtime_events_current_location() does not return a new string
  • in the pid >= 0 code path, it should always be freed, since runtime_events_loc does not escape the function

This PR:

• Fixes these by moving runtime_events_loc's allocation into the relevant branch, rewriting the function to be single-exit after cursor allocation succeeds, and by having both frees state their explicit guards:

https://github.com/ocaml/ocaml/blob/1c337f6d56604663f8b2eb839fe14abfb8230856/otherlibs/runtime_events/runtime_events_consumer.c#L237-L252

• Deduplicates the two identical path-freeing if-blocks in the caml_ml_runtime_events_create_cursor wrapper which calls it, for clarity. This does not change the behaviour of the program.
• Adds a test which tries to reach these cases, though only the double-free (and Windows on the commit before #13089) actually causes a failure of the test.
  • This chmod 000s the ring buffer file in order to cause subsequent read attempts to fail.
  • It uses a slight workaround to find the correct PID and .events file, so it works on Windows (rather than skipping), because I wanted to actually test #13089.
  • The testsuite does fail on this commit.

[^1]: This is the correct behaviour for cursor, since the caller takes ownership of the returned cursor iff the function returns successfully

[eutro]

It looks like, perhaps unsurprisingly, not all platforms work with the new test (though MSVC just had a quite disappointing network error), so I intend to remove it later, since I can't think of a better way to force failure.

[eutro]

I've spotted and fixed another bug, notably Runtime_events.create_cursor None never closing the file descriptor on Unix.

On trunk this crashes after opening too many file descriptors, causing create_cursor None to fail and trigger the existing double-free bug:

let () =
  Runtime_events.start ();
  try
    for _ = 1 to 1024 (* or whatever your [ulimit -n] is *) do
      Runtime_events.(create_cursor None |> free_cursor)
    done
  with _ ->
    Runtime_events.(create_cursor None |> free_cursor)

I also perform cleanup on the Windows handles if the mapping fails.

[NickBarnes]

I'll review this.

[MisterDA]

Should the ring file be also marked non-inheritable on Windows and close-on-exec on Unix?