Fix stalls on ffmpeg based decoder reset

[Wumpf]

What

• Part of Native video decoder via ffmpeg CLI #7607

(All perf numbers on Windows which is well known for slower process handling compared to its competitors.)

Makes the ffmpeg listen/write thread shutdown much more rigorous. It worked fine before, but on Windows in particular I often noticed long stalls:

This happened mostly due to delays in "noticing" that ffmpeg was shut down already. The shutdown fixes themselves, make the problem almost go away. But it still happens that the "listen thread" takes a fair while until it closes:

Occasionally I also still observed 100ms+ for this operation, especially when having several decoders open at the same time (coincidence? did that just make it more likely to get a bad one or is there more to it?). So I decided to have the thread shut down in the background instead - this is safe now, since the on_output callback gets disconnected prior to the shutdown.

No profiler picture for this, since there's nothing left to look at ;-)

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!
• If have noted any breaking changes to the log API in CHANGELOG.md and the migration guide

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

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