GSubprocess win32 fixups

Note: we go out of our way not to pass a child setup function on win32
(even if it does nothing) because we get a g_warning() from gspawn if we
do so.
Don't build gapplication(1) on win32

It's pretty closely tied to desktop files...
Clarify the g_application_withdraw_notification docs

Mention that notifications are dismissed when activated.
gobject: forbid finalization-during-construction

If a constructor() implementation created an object but then unreffed
it rather than returning it, that object would get left on the
construction_objects list, which would cause problems later when that
memory location got reused by another object.

"Fix" this by making it fail intentionally, and add a test for it (and
for the normal, working singleton case).

https://bugzilla.gnome.org/show_bug.cgi?id=661576
gobject: simplify object-in-construction handling

Rather than keeping a global list of objects that are being
constructed, use qdata on the object itself like we do with several
other properties now.

https://bugzilla.gnome.org/show_bug.cgi?id=661576
GKeyfile: don't leak on failed get_(u)int64

In the case that g_key_file_get_(u)int64 fails to parse the integer,
make sure we free the string before returning.

Reported by Andrew Stone <astonecc@gmail.com>

https://bugzilla.gnome.org/show_bug.cgi?id=710313
g_file_error_from_errno: Remove unneeded breaks

Just wasting space

https://bugzilla.gnome.org/show_bug.cgi?id=710625
gdbus: Work around a D-Bus bug with path_namespace='/' match rules

D-Bus versions < 1.6.18 (i.e. all current versions) have a bug with the
path_namespace='/' match rule key. It should conceptually match everything,
but actually matches nothing. This results in no property change (or other)
signals being forwarded to the D-Bus client.

The work-around implemented in GDBusObjectManagerClient is to remove the
path_namespace match key if its value is ‘/’.

For the upstream D-Bus bug, see:
https://bugs.freedesktop.org/show_bug.cgi?id=70799

https://bugzilla.gnome.org/show_bug.cgi?id=710726
GSeekable: document seek-past-end semantics

Introduce the concept of "fixed" vs. "resizable" streams and document
how g_seekable_seek() works for each case.

We don't include g_seekable_is_fixed_size() at this point because we
don't know if anyone would require it.  This may appear in the future if
someone asks for it, however.

https://bugzilla.gnome.org/show_bug.cgi?id=684842
Change semantics of seek on memory output stream

It is our intention that memory output streams should operate in two
distinct modes, depending on if a realloc function was provided or not.

In the case that we have a realloc function (resizable mode), we want
the stream to behave as if it were a file that started out empty.  In
the case that we don't have a realloc function (fixed-sized mode), we
want the stream to behave as a block device would.

To this end, we introduce two changes in functionality:

 - seeking to SEEK_END on a resizable stream will now seek to the end of
   the valid data region, not to the end of the allocated memory (which
   is really just an implementation detail)

 - seeks past the end of the allocated memory size are now permitted,
   but only on resizable streams.  The next write will grow the buffer
   (inserting zeros between).

Some tweaks to testcases were required in order not to break the build,
which indicates that this is an API break, but it seems unlikely that
anyone will be effected by these changes 'in the real world'.

Updates to documentation and further testcases are in following commits.

Based on a patch from Maciej Piechotka <uzytkownik2@gmail.com>.

https://bugzilla.gnome.org/show_bug.cgi?id=684842
GMemoryOutputStream: improve seek tests

Improve test coverage for testing seeking on fixed vs. resizable
GMemoryOutputStream.

https://bugzilla.gnome.org/show_bug.cgi?id=684842
GMemoryOutputStream: docs and whitespace fixes

Document the difference between resizable and fixed-sized streams,
particularly with regards to sizing and seeking.

https://bugzilla.gnome.org/show_bug.cgi?id=684842
file-info: Add a G_FILE_ATTRIBUTE_THUMBNAIL_IS_VALID attribute

This indicates whether the thumbnail (given by G_FILE_ATTRIBUTE_THUMBNAIL_PATH)
is valid — i.e. to represent the file in its current state. If
G_FILE_ATTRIBUTE_THUMBNAIL_IS_VALID is FALSE (for a normal _or_ failed
thumbnail) it means the file has changed since the thumbnail was generated, and
the thumbnail is out of date.

Part of checking thumbnail validity (by the spec) involves parsing
headers out of the thumbnail .png so we include some (small) code to do
that in a separate file.  We will likely want to copy this code to gvfs
to do the same for GVfsFile.

Heavily based on a patch from Philip Withnall <philip.withnall@collabora.co.uk>
who suggested the feature and designed the API.

https://bugzilla.gnome.org/show_bug.cgi?id=709898
gmain: Warn when g_source_remove() fails

Trying to remove a non-existent source should really be
a programming error, as the programmer could be trying to
use the wrong function to remove a callback, as seen when
GtkScrolledWindow tried to remove ID from another function
using g_source_remove().

See https://bugzilla.gnome.org/show_bug.cgi?id=710666#c12

https://bugzilla.gnome.org/show_bug.cgi?id=710724
gmain: test g_source_remove() with invalid ID

Make sure we get the proper critical displayed.

https://bugzilla.gnome.org/show_bug.cgi?id=710724
tests: expect critical on failure to remove source

We've added a g_critical() on failure to remove sources, so make sure we
expect to see that (instead of failing the test due to the unexpected
message).

https://bugzilla.gnome.org/show_bug.cgi?id=710724
gtester: only remove source if not already dead

Don't attempt to g_source_remove() a source for which we already returned FALSE
from the handler.

https://bugzilla.gnome.org/show_bug.cgi?id=710724
gdbus: Ensure message matching always succeeds against path_namespace='/'

This copies the fix from upstream D-Bus bug
https://bugs.freedesktop.org/show_bug.cgi?id=70799 to the GDBusDaemon
implementation, ensuring that matching against path_namespace='/' succeeds
for all keys (i.e. it’s a no-op).

https://bugzilla.gnome.org/show_bug.cgi?id=710726
grand: Document this is not for cryptographic purposes

While this is obvious to seasoned experts upon inspection, it is
really worth documenting explicitly.

https://bugzilla.gnome.org/show_bug.cgi?id=710736
gthemedicon: Fallback to non-symbolic icons

When doing fallback for symbolic icons, we first shorten the name at dashes
while preserving the -symbolic suffix. But after exhausting that, we should also
try stripping the suffix.

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

Signed-off-by: Olivier Brunel <jjk@jjacky.com>

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