The problem occurs because we keep a pointer inside the allocated block,
instead of a pointer to the start of the block:

```
==180238== 16 bytes in 1 blocks are possibly lost in loss record 3,086 of 16,075
==180238==    at 0x483980B: malloc (vg_replace_malloc.c:309)
==180238==    by 0x548942C: g_malloc (gmem.c:102)
==180238==    by 0x54A4748: g_slice_alloc (gslice.c:1025)
==180238==    by 0x53D0AAF: freelist_alloc (gatomicarray.c:77)
==180238==    by 0x53D0B85: _g_atomic_array_copy (gatomicarray.c:133)
==180238==    by 0x53F8E6D: iface_node_set_offset_L (gtype.c:1347)
==180238==    by 0x53F91F1: type_node_add_iface_entry_W (gtype.c:1444)
==180238==    by 0x53F93DF: type_add_interface_Wm (gtype.c:1477)
==180238==    by 0x53FC946: g_type_add_interface_static (gtype.c:2852)
==180238==    by 0x4A3D53A: gtk_menu_shell_accessible_get_type_once (gtkmenushellaccessible.c:26)
==180238==    by 0x4A3D495: gtk_menu_shell_accessible_get_type (gtkmenushellaccessible.c:26)
==180238==    by 0x4C8AC44: gtk_menu_shell_class_init (gtkmenushell.c:424)
```

Note we cannot use VALGRIND_FREELIKE_BLOCK() in freelist_free() because we
have not actually freed the FreeListNode and need to dereference it in
freelist_alloc() to decide whether to reuse the block. That would result
in a use-after-free warning before we would get a chance to call
VALGRIND_MALLOCLIKE_BLOCK() in the reuse path.

Also note that this free list only ever grows: it never shrinks for the
lifetime of the application, so nothing here will ever be truely freed,
although unused elements are eligible for reuse.

Fix suggested by Philip Withnall

Related: #2076

All gobject/*.{c,h} files have been processed.

gmarshal.c and gmarshal.h don't have a license header.

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

This was mostly fixed already, just re-fix a few details here.
https://bugzilla.gnome.org/show_bug.cgi?id=71704

A gsize is never going below 0.

For instance MSVC doesn't like that.

Signed-off-by: Tor Lillqvist <tml@iki.fi>

This adds supports for a lock-less a non-shrinking growable array.
You can use it to do reads using no locks, as long as your read-code
can handle that during the read transaction the object can be modified
by another writer (but it will not change size or be freed), and you
can only trust the result once the transaction has finished successfully.

This doesn't free things like RCU normally does, instead it pushes the
memory on a free list that is reused for other atomic arrays.