RsEventsService: replace global dispatch barrier with a per-handler one (follow-up to #330)

[jolavillette]

RsEventsService: replace global dispatch barrier with a per-handler one (follow-up to #330)

To fix the shutdown use-after-free, #330 makes handleEvent() hold a single recursive mutex (mDispatchMtx) for the whole dispatch, and makes unregisterEventsHandler() wait on it. So that mutex is now held while the event callbacks run - and two of those callbacks are synchronous and blocking (the passphrase request and the plugin-confirmation dialog). Two threads then end up waiting on each other:

1. a background thread requests the PGP passphrase → sendEvent() runs the handler on that thread holding mDispatchMtx, and blocks on the GUI thread via Qt::BlockingQueuedConnection;
2. the GUI thread destroys any widget → its destructor's unregisterEventsHandler() blocks acquiring mDispatchMtx;
3. background waits for the GUI thread, GUI waits for the lock it holds → hard hang.

Before #330, step 2 returned immediately, so no cycle existed.

This PR keeps #330's UAF fix but makes the unregister barrier per-handler instead of global, so callbacks run with no events-service lock held again and a blocking handler only ever delays unregister of itself, without adding work to the dispatch path:

• each registered callback lives in a shared_ptr<Handler> carrying an atomic inFlight counter; handleEvent() snapshots the shared_ptrs (no more std::function copies) and bumps the counter under mHandlerMapMtx, so an unregister either erases a handler before the snapshot or sees it in flight;
• after each callback the counter is decremented; the condition variable is only touched when an unregister is actually waiting (atomic waiter counter), so the common path takes no extra lock and does no allocation;
• unregisterEventsHandler(h) erases h, then waits until its counter drops to the number of times the current thread itself is running it (thread-local frame stack), so a callback unregistering itself, or one re-entered through a nested sendEvent(), never waits on itself.

Exception-safe (not-yet-run handlers are released if a callback throws). Touches only rseventsservice.{cc,h}.

[G10h4ck]

This doesn't look good, AFAIU for every event to handle there are list operations. Handling an event at least prom RsEvent perspective must be something very lightweight...

[jolavillette]

Fair point, the map/multiset bookkeeping was too much for the hot path. I reworked the branch (force-pushed, rebased on master):

• each registered callback now lives in a shared_ptr<Handler> with an atomic inFlight counter; handleEvent() snapshots the shared_ptrs (one refcount bump each, it no longer copies the std::functions as before) and bumps the counter under mHandlerMapMtx;
• after each callback the counter is decremented; the condition variable is only touched when an unregister is actually waiting (atomic waiter counter), so the normal dispatch path takes no extra lock and does no allocation;
• unregisterEventsHandler() erases the handler then waits for its counter, minus the times the current thread itself is running it (thread-local frame stack), so a callback unregistering itself never waits on itself.

Net effect: dispatch is cheaper than current master (one vector reserve per event instead of a list of std::function copies), and callbacks still run with no service lock held so the blocking passphrase / plugin-confirmation handlers can't deadlock a widget teardown.