PangoFcFont has a field `PangoFcFontMap *fontmap`, but at various
places, this field is cast to a `GWeakRef` and used with g_weak_ref_*()
API.

Correctly, all places that set the field, would do so via
g_weak_ref_set(). And "accidentally", sizeof(GWeakRef) is the same as
`sizeof(gpointer)`. The wrong usage happens at the places that access
the fontmap field directly, and assume this is just a plain pointer.

This mostly works. Note that [1] reworked the representation, so while
another thread accesses the GWeakRef (e.g. by destroying the fontmap),
the pointer gets mangled. If the code would then just access the fontmap
field, it would be mangled. Probably that does not happen, and pango
objects are not unreffed or released on other threads. So it somewhat
worked.

But it also relies on internals of glib and (since [1]) it relies that
the object is not destroyed on another thread.

Rework that. Instead of wrongly using a GWeakRef, use
g_object_add_weak_pointer(). That is also not thread-safe, but that
doesn't seem to be a requirement here anyway.

Note that PangoWin32Font has a similar problem. But it's more severe
because it directly assigns pointers instead of using g_weak_ref_set()
(see _pango_cairo_win32_font_new()). That leads to crashes since [1].
This will be fixed next.

[1] glib!3834

Fixes: aca468cd ('Port pangofc-font.c to GWeakRef')