gbookmarkfile: removed unused include 'gslist.h'

https://bugzilla.gnome.org/show_bug.cgi?id=722323
gstringchunk: Use g_slist_free_full() where possible

We have that function, let's use it - instead of manually
freeing the elements of the slist in a loop (and reduce
the line count a bit).

https://bugzilla.gnome.org/show_bug.cgi?id=722326
gio: fix small memory leak on local xattr

g_strconcat() allocates memory, it needs to be freed.

==10653== 1,400 bytes in 50 blocks are definitely lost in loss record
1,838 of 1,851
==10653==    at 0x4A0645D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10653==    by 0x54ACB22: g_malloc (gmem.c:102)
==10653==    by 0x54ACE4D: g_malloc_n (gmem.c:343)
==10653==    by 0x54C8463: g_strconcat (gstrfuncs.c:589)
==10653==    by 0x4D6ED38: get_xattrs_from_fd (glocalfileinfo.c:660)
==10653==    by 0x4D71622:
_g_local_file_info_get_from_fd (glocalfileinfo.c:2028)
==10653==    by 0x4D731A0:
g_local_file_input_stream_query_info (glocalfileinputstream.c:356)
==10653==    by 0x4C996D8:
g_file_input_stream_query_info (gfileinputstream.c:148)
==10653==    by 0x4C863F6: file_copy_fallback (gfile.c:3120)
==10653==    by 0x4C86DD2: g_file_copy (gfile.c:3398)

https://bugzilla.gnome.org/show_bug.cgi?id=722357
GOption: don't use "rand" in code example

rand() is a function defined in the libc, so our code example gives
warnings if you try to compile it.  Fix that.

https://bugzilla.gnome.org/show_bug.cgi?id=722025
g_option_context_parse_strv: use UTF-8 on Windows

Add another difference to the freshly-added g_option_context_parse_strv:
now, on Windows, its arguments on to be in UTF-8 instead of the argv[]
encoding (from the system codepage).

The documentation teases g_win32_get_command_line() which is a new
GLib-filename-encoding-based function that will be added in a following
commit.

https://bugzilla.gnome.org/show_bug.cgi?id=722025
win32: add g_win32_get_command_line()

This returns the command line in GLib filename encoding format (ie:
UTF-8) for use with g_option_context_parse_strv().

This will allow parsing of Unicode commandline arguments on Windows,
even if the characters in those arguments fall outside of the range of
the system codepage.

https://bugzilla.gnome.org/show_bug.cgi?id=722025
g_file_new_for_commandline_arg: clarify encoding

Add a note to the documentation for g_file_new_for_commandline_arg()
that this function is intended to operate on strings already in the GLib
filename encoding on Windows.

This has been the case for a long time, but this documents the
requirement.

https://bugzilla.gnome.org/show_bug.cgi?id=722025
GApplication: change commandline encoding policy

Clarify in the documentation that the commandline arguments passed
around by GApplication (to local_command_line and returned via
g_application_command_line_get_arguments()) are in the GLib filename
encoding (ie: UTF-8) on Windows, not the system code page.

Fix the mismatch that would result from having argv passed to
g_application_run() in main() on Windows (where it is in the system
code page) by ignoring argc/argv on Windows and calling
g_win32_get_command_line() for ourselves.  Document this.

This might be a slight API break on Windows: we documented that it was
possible to call g_application_run() with arguments other than argc/argv
and now doing that will result in those arguments being ignored.  It has
always been recommended practice to only call g_application_run() from
main() directly, however, and all of our code examples have shown only
this.  We will see if this causes any issues and consider reevaluating
the situation if so.

https://bugzilla.gnome.org/show_bug.cgi?id=722025
GOptionContext: add some notes about encodings

Add a note to the overview documentation for GOptionContext about why
you need to be careful about argv encoding on UNIX and about why you
should avoid argv entirely on Windows.  Mention some possible
alternative approaches, including a code example.

https://bugzilla.gnome.org/show_bug.cgi?id=722025
GSimpleAction: add default activate handler

If the action is stateful and the user doesn't have their own activate handler
then do some reasonable things for ourselves.

After a lot of experience using stateful GSimpleAction it turns out that
people almost always end up using it in the same ways:

A boolean-typed stateful action with no parameter is most likely going
to want to be toggled.  Any other type of action that has the parameter
type equal to the state type probably intends for activation to
represent a request to change the state.

This patch implements those two cases.  This will let people stop
writing their own trivial handlers over and over.

https://bugzilla.gnome.org/show_bug.cgi?id=722503
GSimpleAction: fix mistake in last commit

Some bad copy-paste happening here...
Adjust doc to Makefile.decl renaming

g_test_build_filename() API documentation still mentions Makefile.decl, but
it has been renamed to glib.mk in f9eb9eed

https://bugzilla.gnome.org/show_bug.cgi?id=722436
Avoid a deprecation warning

https://bugzilla.gnome.org/show_bug.cgi?id=711547
win32: silence build warning

glocalfileinfo.c: In function '_g_local_file_info_get':
glocalfileinfo.c:1955:11: warning: passing argument 3 of
'get_thumbnail_attributes' from incompatible pointer type [enabled by
default]
           get_thumbnail_attributes (path, info, &statbuf);
           ^
glocalfileinfo.c:1285:1: note: expected 'const struct GStatBuf *' but
argument is of type 'struct _stati64 *'
 get_thumbnail_attributes (const char     *path,

https://bugzilla.gnome.org/show_bug.cgi?id=711547
win32: silence build warning

gdbusauthmechanismexternal.c: In function 'mechanism_client_initiate':
gdbusauthmechanismexternal.c:355:3: warning: 'initial_response' may be
used uninitialized in this function [-Wmaybe-uninitialized]
   return initial_response;
   ^
gdbusauthmechanismexternal.c:332:10: note: 'initial_response' was
declared here

https://bugzilla.gnome.org/show_bug.cgi?id=711547
win32: silence build warning

glocalfile.c: In function 'g_local_file_measure_size_of_file':
glocalfile.c:2654:3: warning: passing argument 2 of 'g_lstat' from
incompatible pointer type [enabled by default]
   if (g_lstat (name->data, &buf) != 0)
   ^
In file included from glocalfile.c:68:0:
../glib/gstdio.h:135:5: note: expected 'struct GStatBuf *' but argument
is of type 'struct _stati64 *'

https://bugzilla.gnome.org/show_bug.cgi?id=711547
Fix the build

The thumbnail-verification test (indirectly) includes individual
headers, so define GIO_COMPILATION to make it work.
Work around broken FreeBSD headers

It seems that including just pthread.h does not define
clockid_t on these systems.

https://bugzilla.gnome.org/show_bug.cgi?id=722526
GMainContext: unref pending sources on destroy

It is possible (but unlikely) that there will be a non-empty list of
pending dispatches when we remove the last ref from a GMainContext.
Make sure we drop the refs on the sources appropriately.

Add a (now-working) testcase that demonstrates how to trigger the issue.

https://bugzilla.gnome.org/show_bug.cgi?id=139699
glib-private.h: add _glib_alignof