Handle automation on processing thread

[DomClark]

Connections that update values for remote plugins are now all DirectConnections. The result is that changes to these values no longer always come from the main thread, but instead from the thread that changed them, which in the case of automation or controllers will be the processing thread.

This fixes the following issues:

• Hangs occurring when the project is saved while Zyn or VSTs are being automated. Value updates were sometimes sent while LMMS was waiting to receive the save data from the remote plugin, resulting in a deadlock trying to lock the plugin mutex twice on the same thread. Sending the update on a different thread solves this. (Fixes LMMS hangs when saving project while automating VSTi's pitch #4543, fixes lmms 1.20 r6 crash when lfo controller use #4584.)
• Stuttering audio during automation of Zyn or VSTs. Since Use tryLock in audio threads for VST/ZynAddSubFX #4460, the plugin mutex is locked using tryLock before getting audio from the remote plugin. If a value was being automated, the main thread was sometimes holding the lock to update the value which caused a buffer of audio to be skipped for the plugin. Sending the automation on the processing thread ensures the updates are finished before audio is rendered. (Fixes VST pitch automation not working #4625.)
• Choppy/laggy/missing VST automation, especially during export. The automation used to get caught up on the main thread (a problem that was much worse on export), but is now delivered immediately on the processing thread. (I can't find an issue for this, but I've seen it mentioned from time to time on the Discord server.)

[PhysSong]

Good point! 👍

[PhysSong]

@DomClark Is it ready to merge?

[DomClark]

I think so, yes.