Fix some more VST bugs

[DomClark]

Remove the lock synchronising access to the VST plugin's methods. The only methods which are called outside of the UI thread are process, processReplacing and dispatcher(effProcessEvents, ...), all of which are intended to be called concurrently with other methods in order to facilitate real-time audio processing. This fixes a deadlock which occurs when a plugin waits on window messages sent to LMMS during an idle call.

I've also taken the opportunity to replace lockShm() with tryLockShm() in RemoteVstPlugin::process so as to remove all potentially blocking calls from that method.

The message sampleRateInformation now waits for a reply since, now we don't have a lock, audio processing shouldn't start before it's complete.

We now always tell the plugin the sample rate and buffer size on load as some plugins (e.g. Amplitube) crash if not given this information.

Fixes #4052.

The audioMasterPinConnected host callback returns 0 now to indicate that all pins are connected. This message is deprecated but some plugins (e.g. iZotope effects) still rely on it and won't produce sound unless told that they are connected.

Fixes #4095.

[tresf]

@DomClark is this ready for merge? I know you had a question on #devtalk about whether or not to combine a second fix.

[DomClark]

Added the second fix now, turned out to be easier than I expected.

In terms of being ready to merge, there is one potential problem I've spotted; it seems unlikely to occur but I'd like to make sure it won't. Most VST calls can be made concurrently with the audio processing calls, but updating sample rate and buffer size can't. Buffer size is set only upon init, but the sample rate is changed when exporting at a non-default sample rate, so if anyone's particularly unlucky with thread scheduling, the sample rate update message won't make it to the VST before processing begins. The result depends on the plugin; best case scenario nothing happens, but worse case scenario the plugin crashes and LMMS hangs. I'll probably address this by making LMMS wait for a reply to IdSampleRateInformation so processing won't begin until everything's ready.

[tresf]

@DomClark per request on Discord, here's a build that contains this fix (please pardon the versioning, it's based off of RC5, not RC4)

https://github.com/tresf/lmms/releases/download/v1.2.0-rc4/lmms-1.2.0-rc4.130-win64.exe

[PhysSong]

@DomClark Are there anything left before merging this?

[DomClark]

I'm not aware of anything else for now, so I'm happy for this to be merged. I can always open another PR if anything new appears.