JACK backend: long-running control layer ops block audio from all apps

[jamshark70]

I'm encountering this in Ubuntu Studio 24.04, which pre-installs Pipewire. I don't know if the same will happen in a pure-JACK system, and I have not tested other audio backends on other OSes.

To reproduce:

1. Run some audio in another app (any backend; when I saw the issue just now, I was playing music in a browser, which I assume is the Pipewire PulseAudio shim).
2. Open PlugData.
3. Make sure the audio settings are configured for JACK. (I couldn't get any audio with ALSA anyway.)
4. Open the else help patch for all else objects. This takes a long time to load. Note that this could be any operation that takes longer than a few control blocks to complete -- I'm suggesting to open "all else objects" because it's an easy action to describe, and on my machine, it takes a couple of seconds before the patch is displayed.

All audio on the system blocks until the operation is finished (the patch is fully loaded).

If this isn't fixable, then I guess close it.

One user impact is that Gem patches often overrun the control period, which causes other apps to drop audio frames. So I can't, for instance, run SuperCollider audio and Gem graphics on the same machine, if Gem is in PlugData (even though I have 16 virtual cores!). I have to run Gem in original Pd, because the audio buffering system means that Pd vanilla can't block the systemwide audio thread.

EDIT: May be related to #2192, but that issue doesn't describe any impact on other apps.