On Windows, broughtToFront may be called during the destructor of
VSTPluginHost, adding the window back into activeVSTWindows, leading to
a heap-use-after-free in vstHookWndProc.

This change means that broughtToFront will only reorder
activeVSTWindows; it will never add a window that's not already in the
list.

This allows paths that are prefixed with environment variables to behave
as expected. This is useful when scanning the default LV2 locations in
the AudioPluginHost on Windows.

Some hosts (e.g. REAPER) will attempt to instantiate plug-ins with 64
active channels, and JUCE can't represent this layout. In this case,
failing to convert between VST3/JUCE layouts is not a logical error, so
asserting is not appropriate.

Previously, all parameter changes were routed first into
cachedParamValues. Then, on each audio callback, an update would be sent
to the editor via the parameterDispatcher for each changed value in
cachedParamValues.

Now, parameter changes are immediately added to the parameterDispatcher,
without needing to wait for an audio callback.

In Windows DLL builds we inject operator new/delete definitions into
classes with a leak detector. This requires that all inheritance from
such classes must be public, and classes inheriting from multiple such
classes must disambiguate between the base's operators.

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.