GApplication: add --gapplication-service switch

Add a --gapplication-service switch to the default implementation of
local_command_line.  This name is unlikely to clash with any option used
by an existing application.

When a normal application (neither service nor launcher) is launched with
exactly this one argument, G_APPLICATION_IS_SERVICE will be set.

The idea is that people will write their D-Bus service file with
--gapplication-service on the Exec line.  This provides a nice
compromise for people who want the benefits of DBusActivatable
applications but without losing the ability to easily run them directly
(under the debugger or inside jhbuild, etc.)

https://bugzilla.gnome.org/show_bug.cgi?id=710965
GApplication: allow handles_commandline and service

The default local_command_line handler has a fast return path for the
case that we handle the commandline by forwarding it to the primary
instance, but this doesn't account for the fact that we may want to
become a service.

Allow for this by making sure we don't take the fast path of the service
flag is set.
GOptionContext: add memory-friendly parse mode

Add g_option_context_parse_strv() that obeys the normal memory conventions for
dealing with a strv instead of assuming that we're dealing with the 'argv'
parameter to main().

This will help for using GOptionContext with GApplication.

https://bugzilla.gnome.org/show_bug.cgi?id=721947
tests: fix leaks in option-context test

Use the new g_option_context_parse_strv() to patch up some leaks in some
insufficiently-argv-emulating testcases in option-context.c.

This gives some test coverage of the new function while also making
option-context now leak-free.

https://bugzilla.gnome.org/show_bug.cgi?id=721947
Updated Hebrew translation
Updated Greek translation
gdesktopinfo: Fix typo in "Since" annotation of has_key
giomodule test: force shared library build

http://lists.gnu.org/archive/html/bug-libtool/2013-05/msg00009.html hit
us again.  libtool only builds .so files if we install the library, so
force it to build for our testcase, even if we don't install it.
giomodule test: fix again

The compiled modules will be in the G_TEST_BUILT directory, not _DIST.
build: fix 'make distclean'

Don't run a non-existent lcov command to clean up during 'make distclean'
more distcheck fixes
GLib 2.39.3
Update .gitignore
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