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.

AU and AUv3 plugins only support version numbers with up to 3 parts.

- Add AlertWindow::show() and showAsync() methods that take a MessageBoxOptions argument
  - Add NativeMessageBox::show() and showAsync() methods that take a MessageBoxOptions argument
  - Update the DialogsDemo to demonstrate the new methods
  - Deprecate AlertWindow::showNativeDialogBox() in favour of the NativeMessageBox methods
  - Pass button strings specified in MesssageBoxOptions to native dialog boxes correctly
  - Use modern TaskDialog on Windows for the native dialog box where available