Add API to support static linking and unloading

When GLib is built as a static library, constructors and destructor
functions are queued up until `glib_[de]init()`. This way the
application may override the heap VTable before GLib starts allocating
memory, which means it is able to release all memory allocated by GLib
without explicit deinit code for every single statically allocated block
of memory. What this means is that only OS handles are left to be
cleaned up, and that's where `glib_deinit()` needs to perform explicit
clean-up.

This is a pragmatic solution to support linking GLib into short-lived
plugins. The goal is to keep this patch as minimal as possible, so it's
easy to keep maintaining it for future GLib versions. (Upstream has no
interest in this use-case.)

Note that `glib_init()` and `glib_deinit()` do absolutely nothing unless
GLib was compiled as a static library.
glib-genmarshal: Call `glib_init()` to support static linking
Add support for naming threads on Windows
Add support for naming threads on Darwin
Work around iOS SDK missing prototype of `_NSGetEnviron()`