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.

Co-authored-by: Dan Raviv <dan@soundradix.com>

Previously, the bus layout was considered invalid if the host provided
an unexpected number of channels on a disabled bus. Specifically,
Acoustica 7 would prepare sidechain input buses with a non-zero number
of channels, but provide a zero-channel bus during processing.

Given that the plug-in doesn't attempt to read from disabled buses, it
should be safe to process as normal in this scenario.

According to the VST3 spec, activateBus and setBusArrangements shall not
be called when a plugin is in the 'activated' state.

Previously, if prepareToPlay was called twice in a row on a hosted VST3
plugin, during the second call the plug-in would already be activated,
but its bus layout would still be adjusted. Now, we always ensure that
the plugin is inactive before the bus properties are adjusted.

This avoids repeating the 'fallback' values in the case that the
AudioPlayHead or PositionInfo is not available.

As a side-effect of this change, when an AudioPlayHead is available but
does not supply a valid BPM value, a fallback of 120 will be used,
instead of 0. This fixes an issue where the Microtonic sequencer failed
to play in the AudioPluginHost.

The ARA SDK's debug functionality is included in the audio_processors
module, hence the configuration had to be moved there from
juce_plugin_client.

Fixes an issue on Windows that caused superfluous HWND messages on DPI aware plugins that resulted in dismissing focused components.

The current minimum-supported Xcode (10.1) includes the macOS 10.14.1
SDK, so APIs from macOS 10.12 will always be available.