gobject: Separate GWeakRef from GWeakNotify

This patch is based upon Garrett Regier's work from 2015 to provide some reliability and predictability to how disposal handles weak reference state.

A primary problem is that GWeakRef and GWeakNotify state is shared and therefore you cannot rely on GWeakRef status due to a GWeakNotify calling into second-degree code.

It's important to ensure that both weak pointer locations and GWeakRef will do the proper thing before user callbacks are executed during disposal. Otherwise, user callbacks cannot rely on the status of their weak pointers. That would be mostly okay but becomes an issue when second degree objects are then disposed before any notification of dependent object disposal.

Consider objects A and B.

A contains a reference to B and B contains a GWeakRef to A. When A is disposed, B may be disposed as a consequence but has not yet been notified that A has been disposed. It's GWeakRef may also cause liveness issues if GWeakNotify on A result in tertiary code running which wants to interact with B.

This example is analagous to how GtkTextView and GtkTextBuffer work in text editing applications.

To provide application and libraries the ability to handle this using already existing API, GWeakRef is separated into it's own GData quark so that weak locations and GWeakRef are cleared before user code is executed as a consequence of GData cleanup.