Previously, we would allocate storage large enough to fit the entire
contents of the input stream, even if this was lower than the
maxNumBytesToWrite.

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.

The significant change here is that the XSaveContext call in the OpenGL
NativeContext now has a matching XDeleteContext call. This breaks the
connection between the X window and the ComponentPeer, so that we avoid
dereferencing a dangling ComponentPeer pointer if the window receives
events after the peer is destroyed.

This can be tested by toggling 'Distortion' on and off in the
DSPModulePluginDemo, and checking the latency reported in the node
statistics in AUM.

The VST3 spec disallows adding/removing parameters at runtime.
As far as I can tell, there's no way for a plugin to signal to the host
that the unitIds of one or more parameters have changed, so I suspect
these are not allowed to change at runtime either.

Given this, I can't think of a good reason for refreshParameterList to
have any effect for VST3 plug-ins.

When the mouse moves from one window to another, the mouseExit event
for the old window can occur after the mouseMove event for the new.
Until this commit this would cause the MouseInputSource to be
associated with the old window, and getComponentUnderMouse() would
incorrectly return a nullptr.

Without this MouseInputSource::getComponentUnderMouse() will report a
stale value after moving the cursor within a single peer using
MouseInputSource::setRawMousePosition().

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.

Xcode 14 has minimum deployment targets of macos 10.13 and iOS 11.