By default, x86_64 binaries are not signed, but arm64 binaries are. When
building universal binaries, it was possible to end up with a final
artefact that contains an unsigned x86_64 image, but a signed arm64
image. In some cases, this could cause issues in subsequent codesign
invocations.

When the result of find_if() is only compared to the container's end(),
the operation can normally be expressed more concisely using any_of(),
all_of(), or none_of().

This commit removes the various compiler-specific JUCE_DEPRECATED macros and replaces them with C++14's deprecated attribute. It also removes the JUCE_CATCH_DEPRECATED_CODE_MISUSE flag as we can rely on the override specifier catching usage of these old virtual methods, and tidies up the DOXYGEN preprocessor checks as they were inconsistent across the codebase.

5f7ad995af introduced an issue where the
string of external libraries would be escaped in one go. This is
incorrect, because only the individual paths should be escaped. The
semicolons separating each path should not be escaped.

Previously, it wasn't safe to access Font instances from multiple
threads because there was a chance that they might reference the same
shared internal state. In this case, calling getTypeface() or getAscent from
two threads simultaneously would cause a race on the typeface and ascent
data members, even though the Font instances appeared to be disjoint.

With this change in place, it is now safe to use Font instances from
multiple threads simultaneously.

It is still an error to modify the same Font instance from multiple
threads without synchronization!

    // Fine:
    Font a;
    Font b = a;

    auto futureA = std::async (std::launch::async, [&a] { /* do something with a */ });
    auto futureB = std::async (std::launch::async, [&b] { /* do something with b */ });

    // Bad idea:
    Font f;

    auto futureA = std::async (std::launch::async, [&f] { /* do something with f */ });
    auto futureB = std::async (std::launch::async, [&f] { /* do something with f */ });

Merging a plist which contained UIBackgroundModes or
UISupportedInterfaceOrientations keys could result in these keys being
duplicated in the generated plist.

This patch will avoid adding a new array if the array's key already
exists in the plist.

Without the BOM, VS assumes UTF-8 strings (subproject file names etc.)
are ansi-encoded.