Guarantee QPFDB::fontEngine() always return non-multi font engine

After QPA refactoring, QWindowsFontDatabase::fontEngine() was returning
a multi font engine w/o any particular reason.
This makes the code more obvious and opens the road to further improvements.

Change-Id: I4858026ddf774d3159c89357b1c905f5112b1c51
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Fix custom font substitution list support

During the QPA refactoring, the custom font substitution list support
was lost by ignoring the font request's fallbackFamilies member
when the multi font engine gets created/initialized.
If fallbackFamilies is not empty, it should be prepended to the
font database default fallback families list. Also respect the
custom fallback families list in the cache key to avoid picking
a multi font engine with wrong fallbacks list.

Task-number: QTBUG-36628

Change-Id: Ie2b84b3a397bee4816f421cddf76a5375829f13a
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Remove need to populate font database on OS X to get fallback families

Populating the whole database takes a while, and it's very easy to trigger
the fallback family code path through eg. matching or getting the default
font family from QFont.

Instead of relying on populate to resolve family name to a PostScript name
(which was required when using CTFontCreateWithName), we instead use the
CTFontDescriptorCreateWithAttributes() function to create a descriptor
based on the family name, and then use CTFontCreateWithFontDescriptor().

The other way around, we use CTFontDescriptorCreateWithNameAndSize, and
then pull out the family name from the descriptor. The need for creating
a CTFont for private fonts (eg '.Apple Symbols Fallback') does not seem
necessary anymore, as tested on 10.7-10.9.

The disadvantage of creating font descriptors instead of re-using the
data computed by population is that we're doing the same work twice,
but the end result is making the font database more lazy, and the 80%
use-case is assumed to be that you're only interested in the fallback
of a small number of fonts, which means you don't want to populate all
of the fonts in the system (taking about 1100ms on the test system).
Looking up the fallback of a single family or style now takes about
15-25ms.

Task-number: QTBUG-37165
Change-Id: I6b904dbe796a3f236919d778d0168fdef9a20e69
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>