This includes Carbon support

This restores the functionality of JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS.
Using this preprocessor flag may avoid Core Graphics rendering much larger regions than
necessary, but the small regions that are rendered will likely be rendered slower.
Whether using this flag improves or degrades the performance of your rendering overall
will be specific to each application.

Previously enabling JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS was ineffective
from versions of macOS around 10.13, but enabling it didn't have any negative impact on
performance. Now enabling JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS may result
in slower rendering.

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 */ });

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