In order to avoid collisions in the JucePlugin_Build preprocessor
definitions, we were only propagating the JUCE_MODULE_AVAILABLE defs
from the shared code target to the plugin wrapper targets.

After this change, we propagate everything *but* the JucePlugin_Build
definitions.

We now link using `-framework Name` instead of `find_library` on iOS, as
suggested here:

https://cmake.org/cmake/help/v3.19/manual/cmake-toolchains.7.html#switching-between-device-and-simulator

Please see the breaking changes doc for details.

Please see the breaking changes doc for details.

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.