g_file_copy: Don't set GError when we intend to ignore errors

For better or worse, the current g_file_copy intention was to ignore
errors copying metadata, but we still set the GError, while returning
TRUE.

https://bugzilla.gnome.org/show_bug.cgi?id=727559
gobject: try to link with -Wl,-z,nodelete

Since the type system does not support reloading its data and assumes
that libgobject remains loaded for the lifetime of the process, we
should link libgobject with a flag indicating that it can't be unloaded.

https://bugzilla.gnome.org/show_bug.cgi?id=707298
giomodule: Add a NULL guard to extension_point_get_extension_by_name

... otherwise a NULL input will lead to a crash in strcmp.

https://bugzilla.gnome.org/show_bug.cgi?id=727964
g_str_has_prefix: don't call strlen(str)

There's no reason to check the length of @str in g_str_has_prefix(),
since if it's shorter than @prefix, the strncmp() will fail anyway.
And besides making the function less efficient, it also breaks code
like:

    if (buf->len >=3 && g_str_has_prefix (buf->data, "foo"))
      ...

which really looks like it ought to work whether buf->data is
nul-terminated or not.

https://bugzilla.gnome.org/show_bug.cgi?id=727890
gapplication-tool: fix a typo

This must have never worked.

https://bugzilla.gnome.org/show_bug.cgi?id=727928
gapplication-tool: ensure object paths are valid

Hyphens are not valid characters for DBus object paths; see the similar
code in gapplicationimpl-dbus.c

https://bugzilla.gnome.org/show_bug.cgi?id=727928
gparam: Add G_PARAM_READWRITE to GParamFlags

Using a #define for an enumeration value buys us nothing, and it's
mostly historical baggage that makes binding GObject needlessly
complicated.

https://bugzilla.gnome.org/show_bug.cgi?id=726037
Deal with startup notify id being NULL

The app launch context may just not support startup notification,
in which case, g_app_launch_context_get_startup_notify_id() will
return NULL.

Failure to take this into account leads to criticals like this:
gnome-session[8489]: GLib-CRITICAL: g_variant_new_take_string: assertion 'string != NULL' failed
gnome-session[8489]: GLib-CRITICAL: g_variant_new_variant: assertion 'value != NULL' failed
gnome-session[8489]: GLib-CRITICAL: g_variant_get_type: assertion 'value != NULL' failed
gnome-session[8489]: GLib-CRITICAL: g_variant_type_is_subtype_of: assertion 'g_variant_type_check (type)' failed

https://bugzilla.gnome.org/show_bug.cgi?id=728066
openbsd: remove -pthread

This is not needed any longer; libpthread is properly included in
shared libs on OpenBSD where -pthread -lpthread mean the same.
gdesktopappinfo: Initialize sn_id to NULL

Otherwise we'll be freeing a random stack pointer.
gdesktopappinfo: Don't double free sn_id

Not sure why mclasen added a g_free() in that path, it was just wrong.
We free it correctly later.
build: also unset LIBS when LDFLAGS is unset

On OpenBSD, libintl is installed under /usr/local/lib. When configure
checks unset LDFLAGS, LIBS should also be unset otherwise we end up with
-lintl which cannot be found resulting to the compile check to fail.

https://bugzilla.gnome.org/show_bug.cgi?id=727939
desktop-app-info test: use g_assert_strcmp()

Replace some assert(strcmp()) with g_assert_strcmp() so that we get
better output in case of failures.

https://bugzilla.gnome.org/show_bug.cgi?id=728040
mimeapps test: fix defaults vs. recommended

The desktop file for myapp3 didn't declare support for image/png, but
the testcase expects it to be recommended on the basis of it being the
default app according to defaults.list.

This will not work in the future -- we will only list apps that actually
support the filetype in question, unless they've been explicitly added
as associations.

https://bugzilla.gnome.org/show_bug.cgi?id=728040
tests: expand 'apps' tool

Add modes to output the applications found for get_default_,
get_recommended_, get_fallback_ and get_all_for_type().

https://bugzilla.gnome.org/show_bug.cgi?id=728040
appmonitor test: avoid /usr/share

Set XDG_DATA_DIRS to make sure we don't use /usr/share from the
appmonitor test.  We will soon throw a warning if we find defaults.list,
so make sure we don't open ourselves up to that if there is one on the
system.

https://bugzilla.gnome.org/show_bug.cgi?id=728040
mimetype tests: don't depend on specific behaviour

We currently assume that setting an application as the default will take
it to the front of the list of supported applications for a given type,
but this is not necessarily true.

Check instead that the application is actually set as default.

https://bugzilla.gnome.org/show_bug.cgi?id=728040
GDesktopAppInfo: rewrite content type code

Redo the code for type-based selection of applications (all,
recommended, default, fallback) based on the new DesktopFileDir
structures that we introduced last cycle.

At the same time, we expand the functionality to add support for the new
features of the specification:

 - moving ~/.local/share/applications/mimeapps.list to ~/.config/

 - per-desktop default applications (via XDG_CURRENT_DESKTOP)

 - sysadmin customisation of defaults (via /etc/xdg/mimeapps.list)

 - deprecation of the old defaults.list, favouring the use of
   /usr/share/applications/mimeapps.list (or gnome-mimeapps.list) to
   accomplish the same

We modify the mimeapps testcase to check for mimeapps.list having been
created in XDG_CONFIG_HOME instead of XDG_DATA_HOME.

The modification is a net reduction of code (due to less duplication in
bookkeeping).  It is also an increase in performance and reduction in
memory consumption (due to simplified data structures).  Finally, it
removes the stat-based timestamp checking in favour of the
GFileMonitor-based approach that was already being used in the
implementation of DesktopFileDir (in order to know if we had to rescan
the desktop files themselves).

https://bugzilla.gnome.org/show_bug.cgi?id=728040
tests: use mimeapps.list over defaults.list

defaults.list is deprecated, so use mimeapps.list as a filename instead.

https://bugzilla.gnome.org/show_bug.cgi?id=728040
gio: fix g-i annotations in g_settings_schema_source_list_schemas()