This change ensures that it is possible to put a plugin in an unprepared state
by calling releaseResources().

read() now returns failure in the case of a read timeout, or if
reading any block failed.

Changed the lifetime of the default MIDI oputput.
Removed the need for Timer workaround in AudioDeviceSelectorComponent.

This fixes an issue where Harrison XT-series plugin editors did not
update on mouse interaction in the AudioPluginHost.

This change reshuffles the way that parameter updates and notifications
work for hosted VST3 plugins.

Previously:
- Parameter::setValue would update the processor and editor, but not the
  host
- Parameter::setValueFromEditor would update the processor and host, but
  not the editor
- MIDI CC events would be converted to events and added to the
  processor's input event list, but were not forwarded to the
  IEditController.

Now:
- Parameter::setValue updates the host's cachedParamValues, which is the
  host's source of truth for parameter values. On each process callback,
  changes will be added to the input parameter list. Then, for each item
  in the parameter list, an update will be dispatched back to the
  editor.
- Parameter::setValueFromEditor is removed. All parameter changes will
  be sent back to the editor, even if they originated from the editor.
  setValueNotifyingHost can be used to notify listeners that one of the
  host's JUCE parameters has changed, e.g. in the host context's
  performEdit.
- MIDI CC events trigger calls to setValueNotifyingHost on any mapped
  parameters. The flow is very similar to a parameter change from the
  editor: the cachedParamValues are updated immediately, and host
  parameter listeners are notified. Then, for each changed
  cachedParamValue an entry is added to the inputParameterChanges
  (updating the processor), then for each item in the
  inputParameterChanges an update is sent to the editor.

This includes Carbon support

This is intended to fix two issues:
- In REAPER, setting automation recording to 'Latch', recording some
  automation, saving and reloading the project, then starting playback causes
  automation data to be overwritten. This appears to be because REAPER
  interprets parameter change messages sent during state restoration as
  originating from the user.
- In Ableton Live, automation lanes are sometimes disabled when loading
  projects. This also seems to be because the setStateInformation call
  may send parameter change messages back to the host.

According to the docs for kAudioUnitProperty_ClassInfo, the host is
required to notify all parameter listeners that the parameter values may
have changed, implying that the plugin need not send its own parameter
change notifications during state restoration.

Some AUv3 presets crash when querying the set of presets in Loopy Pro.
The issue seems to be because `addPresets` may end up being called
concurrently with the host's queries.

Some AUv3 presets crash when querying the set of presets in Loopy Pro.
The issue seems to be because `addPresets` may end up being called
concurrently with the host's queries.

Previously, preparing an AudioProcessorGraph containing hosted LV2
plugins would recreate the plugins and then set their state. For plugins
without threadsafe restore, setting the state would take the
callbackLock to avoid races with processBlock. This meant that

- During prepare, the graph would take the processorLock, then the
  processor would take its own callbackLock.
- During playback, the graph would take the processor's callbackLock,
  and then would take the node's processorLock.

This is probably benign (prepare shouldn't be called concurrently with
processBlock at all), but to be on the safe side we now avoid taking the
callbackLock when setting new plugin state during prepareToPlay.

This is an implementation detail for the build system of the plugin.
Users of the plugin should not know or care that this extension is
available.