Bugfix CoreAudio deadlock when opening a device

[ruurdadema]

This PR proposes a fix for a deadlock which could happen when using Apple's internal audio devices, especially right after changing the sample rate of the device.

This problem was brought up on the forum and discussed on StackOverflow.

Since I couldn't find and haven't received any responses or guidance about what is allowed in terms of synchronising the audio callbacks with the main thread, I've chosen to implement a solution the safe way. What this solution does is replace a ScopedLock with a ScopedTryLock and early return when the lock was not acquired. The only disadvantage I can think of is that in worst case a buffer of audio might be missed, but since the callback lock is only used during starting and stopping of devices I think the tradeoff is fair.

Another solution (as proposed on the forum) would be to unlock the callback lock around AudioDeviceStart(), but since we have no official text from Apple on synchronising audio callbacks, I think it's safer/better to go for the solution in this PR.

I'm also more than happy to discuss alternatives or to improve the solution.

[reuk]

A fix for this issue has been added here: https://github.com/juce-framework/JUCE/commit/455c865d372a138eec4de64d38ce8074d542190e

Please try this out and let us know if you still encounter problems.