Previously, if `AudioProcessorGraph::prepareToPlay` was called twice,
interspersed with calls to `setProcessingPrecision`, the graph would
consider the nodes 'prepared' on the second call, and wouldn't
re-prepare the inner nodes with the new precision setting.

    graph.setProcessingPrecision (juce::AudioProcessor::singlePrecision);
    graph.prepareToPlay (44100, 512);

    graph.setProcessingPrecision (juce::AudioProcessor::doublePrecision);
    graph.prepareToPlay (44100, 512); // this wouldn't update the nodes

Now, we always explicitly unprepare all nodes at the beginning of
prepareToPlay, so that they'll always receive the newest settings.

This commit adds tests and fixes some potential crashes caused by
out-of-bounds reads.

Requesting a callback when opening an Oboe device is required on some devices to get a FAST stream, so pass a dummy callback object to the temporary stream used when querying the device buffer size in order to get the best available.

If input channels have been requested but no data is being sent from CoreAudio (usually due to permissions not being granted yet) then avoid waiting unnecessarily in AudioIODeviceCombiner::readInput() which could previously cause audio glitches. Also changed the wait time to use an exponential backoff.

Some hosts (such as Reaper) weren't creating an instance of exactly
NSOpenPanel or NSSavePanel, which meant that the call to
`getSelectedPaths` was always returning an empty array.

Now, rather than trying to cast the sender to an appropriate type, we
assume that the sender is always the same panel that we opened earlier,
so that we can just query the panel directly for its selection.

Previously, the `JUCE_APP_CONFIG_HEADER` macro wasn't being defined/included
in some of the wrapper files, which meant that there was a danger of these
files building without important JucePlugin_Build_* macros defined.

Previously, when a file dialog was launched synchronously, the 'dummy' modal
component was preventing user input events from reaching the preview component.

Now, we explicitly allow input events to reach the file preview component, if
it exists.

If the preview is not removed from the desktop, the FileChooser will try to reuse
the same ComponentPeer the next time the preview component is used.

Previously, when the FileChooser::Native instance entered the
modal state, it was preventing the inner FilePreviewComponent from
receiving events.

The Win32NativeFileChooser was taking ownership of itself
in its `Thread::run` implementation. This meant that sometimes
the destructor of the file chooser thread would execute directly
in `Thread::run`.

Now, we explicitly transfer ownership into a function object which
will run asynchronously on the main thread. This way, the file chooser
thread will be stopped on the main thread.