The PushNotificationsDemo is not supported on Windows, so I've
stopped CMake from configuring it in the first place.

This change should mean that if JUCE is installed using one compiler
(e.g. clang) and then consumed in a build that uses a different compiler
(e.g. gcc), the helper targets will use the correct flags for both
compilers.

This change gives projects more flexibility to e.g. pre-build
juce_audio_plugin_client into a staticlib and to reuse it in several
targets.

The CoreAudioKit (and on macOS, AudioUnit) frameworks are required to
host AudioUnit plugins. Hosts (especially those which don't use the
`juce_audio_utils` module) should use the new `PLUGINHOST_AU` parameter
to `juce_add_*` in order to add the correct preprocessor definition and
link the necessary frameworks.

Fixes an issue where VST3 plugins would appear to link successfully, but
fail to load in hosts due to missing symbols.

On Linux, all these target kinds tried to create products with the same
name. Now we place each plugin target into a folder named after the
plugin kind, which allows each plugin kind to produce artefacts which
share names.

This change means that imported juce modules will be made available both
with and without a namespace prefix, e.g. `juce_core` and
`juce::juce_core` will both be created.

This change allows custom modules to specify dependencies without a
juce:: prefix, which allows the modules to be used with the Projucer, or
under CMake with JUCE in a subdirectory, or under CMake with JUCE
installed to the system.

Building AudioUnits with an older CMAKE_OSX_DEPLOYMENT_TARGET
(e.g. 10.9) but a newer sdk (e.g. 10.15) would result in link
failures. Linking against the AudioUnit framework supplies the
missing symbols.

AudioUnits built with the Projucer also link CoreAudioKit, so
we do that in CMake too for consistency.

The module binary now has the extension `.so` instead of `.vst3`.

This change helps to avoid ambiguity in includes when building projects
which contain more than one "BinaryData.h".