gconstructor: install as a proper header

https://bugzilla.gnome.org/show_bug.cgi?id=627423
gcleanup: Implementation of GCleanupList and associated macros

Add a new type GCleanupList that stores a list of things to "clean up"
when g_cleanup_list_clear() is called.

More importantly, define some macros (G_CLEANUP, etc) that
facilitate conditionally building a per-library/executable cleanup list
if G_DEBUG=cleanup is specified.  The cleanup list is run at destructor
time.

-DG_CLEANUP_SCOPE defines the name of the cleanup list and enables the
feature for a given module.

Concept and initial work: Ryan Lortie <desrt@desrt.ca>

https://bugzilla.gnome.org/show_bug.cgi?id=627423
Make some use of G_CLEANUP_ADD

This is enough to get a few testcases running with zero memory in use at
the end.

Tweaked by: Stef Walter <stefw@redhat.com>

https://bugzilla.gnome.org/show_bug.cgi?id=711744
memcheck: Add a 'make memcheck' target that runs valgrind

Checks for memory errors and leaks

https://bugzilla.gnome.org/show_bug.cgi?id=711744
gthread-posix: Don't use gslice allocated GRecMutex

This leads to problems during cleanup, and seems strange
to have locks defined in terms of things that need locking.

https://bugzilla.gnome.org/show_bug.cgi?id=711753
GThread posix: add impl structs to cleanup list

There are two ways of using the structs like GMutex, GCond, etc.

The first is to explicitly _init() and _clear() them.  This is when you
use them as part of another structure.  This case is not interesting for
gcleanup.

The other is to have them in static storage (zero-filled) and just use
them for the first time.  This is the difficult case, because we don't
ever free the impl in that case.

In the first case, the impl is created and set in the _init() function.
We can therfore tell that we are in the second case if we get to the
get_impl() function and the impl is not there yet.  In that case, add it
to the cleanup list.

There are probably people that allocate a GMutex as part of a
zero-filled structure and use it, then call g_mutex_clear() on it.  This
is technically a violation of the API and these users will crash with
G_DEBUG=cleanup, but that's a good thing because it will cause them to
fix their code.

All threading primitives are cleaned up on the graveyard shift, so that
they can be used by other cleanup functions is libglib.

Because GPrivate has a callback, and we need to run that callback for
the main thread, we schedule two cleanups for it. The cleanup needs
to run in the cleanup scope where the GPrivate callback is defined,
so adapt G_PRIVATE_INIT to do this.

Tweaked by: Stef Walter <stefw@redhat.com>

https://bugzilla.gnome.org/show_bug.cgi?id=711744
gcleanup: Add in more gtestutils.c cleanups

https://bugzilla.gnome.org/show_bug.cgi?id=711744
option-context: Fix leaks in tests

https://bugzilla.gnome.org/show_bug.cgi?id=627423
glib: Define cleanup lists for glib tests

This allows G_CLEANUP to be used in the tests, and from things
like G_PRIVATE_INIT and so on.

https://bugzilla.gnome.org/show_bug.cgi?id=711744
gcleanup: Hook up more libglib globals to cleanup

https://bugzilla.gnome.org/show_bug.cgi?id=711744
gmessages: Initialize GPrivate so it gets cleaned up

https://bugzilla.gnome.org/show_bug.cgi?id=711744
642026: Run less locking iterations under valgrind

Otherwise these tests are prohibitively slow.  Under valgrind the
same race conditions aren't likely to show up anyway.

https://bugzilla.gnome.org/show_bug.cgi?id=711744
mainloop-test: Fix uninitialized memory access in tests

https://bugzilla.gnome.org/show_bug.cgi?id=711751
slice: Don't run GSlice tests under valgrind

https://bugzilla.gnome.org/show_bug.cgi?id=711744
sources: Fix leaks in tests

https://bugzilla.gnome.org/show_bug.cgi?id=711751
threadpool-test: Fix leaks in tests

https://bugzilla.gnome.org/show_bug.cgi?id=711751
threadpool-test: Cleanup memory in test

https://bugzilla.gnome.org/show_bug.cgi?id=711744
gthreadpool: Cleanup thread pool unused threads

This requires different phases getting involved:
 * early: Signal all the unused pool threads, and change unused
   limits to zero, so no new unused pool threads.
 * default: Join all unused pool threads.
 * late: Free up the unused thread queue

https://bugzilla.gnome.org/show_bug.cgi?id=711744
gmodule: Cleanup main_module, ie: self

https://bugzilla.gnome.org/show_bug.cgi?id=711767
gobject: Define a cleanup scope for libgobject

https://bugzilla.gnome.org/show_bug.cgi?id=711778