plugins, util: Prioritize stop events over processing

[Dankirk]

Description

For WaitForMultipleObjects() the order of handles determines priority. This puts stop events as the first handle where appropriate to allow threads to exit when system is busy and multiple waited events are signaled at the same time.

A potential problem with the re-prioritizing is that it might leave queued data unprocessed, so I added some handling where it could matter, but ignored the parts where it shouldn't.

---

Some additional changes for Windows ipc pipe (game capture):

• Check for stop event at beginning of the server thread, in case the game capture never actually readies itself
• Change waited ready_event to be manual resetting as suggested for asynchronous ConnectPipe and OVERLAPPED struct in general
  • Manual seems correct, since WaitFor* is followed by GetOverlappedResult with wait true. (Earlier this worked with auto only because for stopping we also call cancelIoEx from outside the thread, which is not necessary anymore). The event is also reset by ReadFile despite being manual and restarting pipe re-creates the events.
• Instead of exiting right away when stop_event is signaled or WaitForMultipleObjects fails altogether, cancel current io and wait for completion in GetOverlappedResults, so that race conditions to pipe->overlap and writes to to-be-freed buf can be avoidded if pipe is restarted.
• Since the pipe contents could be important (altough currently only used for game capture where it's not), flush the currently pending data before stopping if both events were signaled

---

For rtmp-windows.c I only added a robustness check for abandoned handles. It doesn't wait for its stop_event in socket_thread_windows_internal() at all, but it instead should work through send_thread_signaled_exit event regardless of WaitForMultipleObjects() handle order, so I left it as it was.

Motivation and Context

Noticed this being a potentially problematic pattern around the codebase when fixing a hang issue for captions. (#12729)

How Has This Been Tested?

Tested game capture (ipc pipe) that it works and closes itself properly, though extra eyes could be useful here.

Types of changes

• Bug fix (non-breaking change which fixes an issue)

• Tweak (non-breaking change to improve existing functionality)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[Dankirk]

After taking a bit deeper dive into the current implementation of ipc pipe, I updated the way pipe-windows.c handles stop_event from the initial commit.

Already updated the description, but here's the important bits:

• Change waited ready_event to be manual resetting as suggested for asynchronous ConnectPipe and OVERLAPPED struct in general
• Instead of exiting right away when stop_event is signaled or WaitForMultipleObjects fails altogether, cancel current io and wait for completion in GetOverlappedResults, so that race conditions to pipe->overlap and writes to to-be-freed buf can be avoidded if pipe is restarted.