win32: fix font_face hashing

win32: Use a font_face hash table to provide unique font faces

win32-font: Improve static data reset function

Bug 717178. Part 2: Import changesets eb29a25d, 6e3e3291 and 101fab7c from upstream.
======

From 101fab7cd8a90f7cf3d8113c792b3f8c2a9afb7d Mon Sep 17 00:00:00 2001
The hashtable is guaranteed to only contain font faces which are
currently referenced, hence there is no need to remove any font face
when it is reset (just like for toy-font).

This makes the function simpler and fixes the assertion

Assertion failed: predicate != NULL, file cairo-hash.c, line 373

hit by multiple tests (the first one being "clear").

See https://bugs.freedesktop.org/show_bug.cgi?id=38049

======

From eb29a25dd6dddc511388bf883c9b95843ecdb823 Mon Sep 17 00:00:00 2001
Similar to the freetype and toy font backends, use a hash table
to map logfont,hfont to font faces.

This fixes the multiple embedding of the same font in PDF.

https://bugs.freedesktop.org/show_bug.cgi?id=24849

======

From 6e3e329170ab4b96bc0d587c8071e869e228e758 Mon Sep 17 00:00:00 2001
some bugs were discovered while testing with firefox

======

--HG--
extra : rebase_source : 6bbb299194f2296522e36bfeb68d1e8ebc2d1f17
Bug 717178. Part 3 alternative: don't put Win32 cairo_font_face_ts into the font-face cache if they were created with an explicit HFONT. r=jrmuizel

--HG--
extra : rebase_source : 8bbba7328f422807de458cb64e0e5ce4e8060b31