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
gmain: Fix use of uninitialized memory in sigaction structure

https://bugzilla.gnome.org/show_bug.cgi?id=711754
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
private: Fix memory leak in tests

Don't use g_private_new(), it's deprecated, and leaks by definition.

https://bugzilla.gnome.org/show_bug.cgi?id=711751
private: Use threading primitives correctly in private test

We shouldn't be clearing statically allocated mutexes, and also
no auto-initialization of stack allocated GPrivate.

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

https://bugzilla.gnome.org/show_bug.cgi?id=711744
gerror: Don't leak memory when overwrite warning

Even though we can't always make no-leak guarantees when g_warning()
in this case we're testing this behavior in tests, and it would be
good to be able to valgrind this.

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

https://bugzilla.gnome.org/show_bug.cgi?id=711744
unix: Fix memory leak in unix test

https://bugzilla.gnome.org/show_bug.cgi?id=711751
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
asyncqueue-test: Fix leaks in tests

https://bugzilla.gnome.org/show_bug.cgi?id=711751
child-test: Fix leak in test

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

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