Fix possible hang when using torch.multiprocessing

[jleibs]

What

• Resolves: Hang when using torch.multiprocessing after having called rr.init #6223

Although we already have a fork-handler that cleans up our global/thread-local recording streams, it's apparently still possible for an allocated PyRecordingStream to leak into the subprocess via fork (at least based on how pytorch multiprocessing works).

During __del__, we make one last call to a non-blocking flush.

While previously this was fine, we added an internal blocking batcher flush to our non-blocking sink flush, which still hangs for the same reason (the batcher processing thread is gone in the fork).

The fixes:

• Add a new unit test that repros the error.
• Check for is_forked_child in all the methods that issue inner.batcher.flush_blocking()
• Check for is_forked_child from __del__ and don't call flush to avoid getting a gratuitous warning printout.

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested the web demo (if applicable):
  • Using examples from latest main build: rerun.io/viewer
  • Using full set of examples from nightly build: rerun.io/viewer
• The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG
• If applicable, add a new check to the release checklist!

• PR Build Summary
• Recent benchmark results
• Wasm size tracking

To run all checks from main, comment on the PR with @rerun-bot full-check.