This allows real-time threads to join an audio workgroup on Apple platforms.

float comparison

This patch also updates the MidiDemo to automatically refresh the device
lists when the set of available devices changes.

The issue affected projects not depending on juce_audio_devices.

Previously, whenever the output device sample time changed from
'invalid' to 'valid', the AudioBuffer fifo in the AudioIODeviceCombiner
was cleared. This caused a data race, since the clear operation was not
mutually exclusive with writes from the input device.

This change causes the AudioIODeviceCombiner to keep track of the
timestamp of the first input device callback after the output device is
invalidated. The output device is unable to read from the fifo until its
timestamp exceeds the stored input device callback timestamp.

Previously, JUCE_ANDROID_REALTIME_THREAD_AVAILABLE sometimes remained
unset, even though JUCE_USE_ANDROID_OBOE was set to its default value.
This is because in this case, JUCE_USE_ANDROID_OBOE is only defined in
juce_audio_basics.h, so it is not visible when compiling juce_core.cpp.

Prior to this commit it was not possible to deactivate the first few
channels of an audio device. If say channel 5 was active in the
requested configuration then all channels up to 5 would be active as
well regardless of the provided activation pattern.

As opposed to the number of hardware output channels.

Until this commit CoreAudioIODevice could report inconsistent information in its
getActiveOutputChannels() and getOutputChannelNames() functions, and for
inputs as well. The reason for this was that a sudden configuration change
would immediately be reflected by the CoreAudioInternal::Stream::chanNames
member because those are read in the Stream's constructor. The activeChan
member would however just store stale values, until the Stream was recreated
later during device reopen.

This issue could lead to the AudioPluginHost crashing when opening a
Bluetooth headset.

This is a breaking change - see BREAKING-CHANGES.txt

While the affected callbacks are cancelled before the referenced
state is deleted, we have had user reports that they can still be
accessed by the cancelled callbacks causing crashes. After only
finding warnings that WinRT AsyncCallback cancellation is not a
guaranteed thing, we saw it best to wrap the pointers.