Fixing a regression introduced in da38c1ed.

Before this commit an already started timer would wait until the
previously set tick time before applying the new one. This problem seems
to have affected the Windows implementation only.

Prior to 26a23dfc the Android project exporter requested the Bluetooth
permission by default, and some PIPs depended on this behaviour.

The issue affected projects not depending on juce_audio_devices.

Prior to this fix a data race could occur on 
ARAAudioSourceReader::hostReader between the functions 
didEnableAudioSourceSamplesAccess() and readSamples().

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.

abspath doesn't cope very well with paths that contain spaces, even if
those spaces are escaped.

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.