In particularly unfortunate cases, the fonts used for laying out and
drawing an AttributedString could end up differing, meaning that
incorrect glyph indices would be used during rendering. The rendered
text would end up using incorrect character symbols, making it
unreadable.

The problem seems to be:
- The AttributedString fetched a typeface during the getOrCreateFont
  call in createCFAttributedString.
- Details of the typeface (its style and name) were stored into the
  CFAttributedString.
- During `createLayout`, a new `Font` object was created using the
  stored typeface name and style.
- When calling `getTypeface` on this new font, during rendering,
  a different typeface was returned.

The fix implemented here stores the Font objects used during the
creating of the CFAttributedString, so that the fonts written to
the juce::AttributedString are guaranteed to match the fonts used
to compute the layout.

This fixes warnings that are emitted when building with the `-analyze`
flag enabled.

Previously, the following plugins were causing issues when hosting their
editors:

- Softube plugins. I used Saturation Knob for testing, which crashed when
  deleting the temporary parent view.
- KORG Gadget series, which displayed a black screen after the temporary parent
  view was deleted.
- FabFilter Pro-C, which displayed at the wrong scale when opened on a
  retina display.

On Windows, calls to `createSystemTypefaceFor` with a data buffer always
create a WindowsTypeface instance. However, calls with an existing
`Font` instance may try to create a WindowsDirectWriteTypeface, and will
only fall back to using a WindowsTypeface on failure.

Previously, a missing typeface wasn't treated as a failure, which meant
that `WindowsDirectWriteTypeface` would fall back to the first usable
typeface it could find.

With this change applied, we check whether the
WindowsDirectWriteTypeface actually managed to find the font we
requested, and will fall back to using a plain WindowsTypeface in that
case.