Support Building Using Visual Studio 2013

Like the Visual Studio 2012 project files, the Visual Studio 2013 files are
largely the same as the Visual Studio 2010 project files, so support
Visual Studio 2013 by updating the autotools scripts that is used for
Visual Studio 2012.  This means that project files for Visual Studio 2012
and Visual Studio 2013 can be maintained by simply maintaining the Visual
Studio 2010 project files, adding minimal maintenance overhead.
valgrind.h: Update to latest upstream version

Avoid crashes in g_type_free_instance() on mingw64.

https://bugzilla.gnome.org/show_bug.cgi?id=730198
Add a test for GMenuAttributeIter
gobject: add 'explicit notify' GParamSpec flag

Add a flag to prevent the automatic emission of the "notify" signal
during g_object_set_property().

If this flag is set then the class must explicitly emit the notify
for themselves.  This is already standard practice on most classes, but
we cannot simply remove the existing behaviour because there are surely
many cases where it is needed.

https://bugzilla.gnome.org/show_bug.cgi?id=731200
test: add test for explicit-notify properties

https://bugzilla.gnome.org/show_bug.cgi?id=731200
gtype: guard uses of new fundamental type check

g_type_is_fundamentally_a (see bug 730984) is a new API/ABI and is
marked with a version macro.  We should therefore avoid its
unconditional use from G_IS_OBJECT() and G_IS_PARAM_SPEC() which are
APIs that have been around for a long time.

This prevents deprecation warnings from being emitted when these
functions are used with an older GLIB_VERSION_MAX_ALLOWED and also
prevents linking to the new ABI in that case (so that it's possible to
use the resulting binary with an older version of GLib).

https://bugzilla.gnome.org/show_bug.cgi?id=731335
gatomic: fix typo in deprecation attribute

https://bugzilla.gnome.org/show_bug.cgi?id=730807
gatomic: whitespace fixes

https://bugzilla.gnome.org/show_bug.cgi?id=730807
gatomic: use GCC C11-style atomics, if available

GCC does not yet support ISO C11 atomic operations, but it has
compatible versions available as an extension.  Use these for load and
store if they are available in order to avoid emitting a hard fence
instruction (since in many cases, we do not need it -- on x86, for
example).

For now we use the fully seqentially-consistent memory model, since
these APIs are documented rather explicitly: "This call acts as a full
compiler and hardware memory barrier".

In the future we can consider introducing new APIs for the more relaxed
memory models, if they are available (or fall back to stricter ones
otherwise).

https://bugzilla.gnome.org/show_bug.cgi?id=730807
gthread: use inline keyword for _get_impl() functions

Give compiler a hint that these should be inlined,
which doesn't seem to happen by default with -O2.
Yields 5% speedup in artificial benchmarks, and
1% speedup in a real-world test case doing a lot
of mutex locking and unlocking.

https://bugzilla.gnome.org/show_bug.cgi?id=730807
Revert "GObject: prevent installing properties after init"

This reverts commit ddb0ce14215cd62c7a2497d6cf9f2ea63c40ebb5.

Conflicts:
	gobject/gobject.c

https://bugzilla.gnome.org/show_bug.cgi?id=698614
docs: warn about installing properties after init

Leave ourselves a little wiggle room: if people install properties after
initialisation then we reserve the right to handle that in a way that
may not be threadsafe.

https://bugzilla.gnome.org/show_bug.cgi?id=698614
trivial: docs: add some missing commas
MSVC 2010+ Projects: Update "Installation" Process

Currently, due to the way that Visual Studio 2010+ projects are handled,
the "install" project does not re-build upon changes to the sources, as it
does not believe that its dependencies have changed, although the changed
sources are automatically recompiled.  This means that if a part or more
of the solution does not build, or if the sources need some other fixes
or enhancements, the up-to-date build is not copied automatically, which
can be misleading.

Improve on the situation by forcing the "install" project to trigger its
rebuild, so that the updated binaries can be copied.  This does trigger an
MSBuild warning, but having that warning is way better than not having an
up-to-date build, especially during testing and development.
gtype: remove interface-after-init exceptions

A year ago, we tried to remove support for adding interfaces on
already-initialised types.  There were problems with the C++ and C#
bindings at the time, so we added exceptions to give them a bit more
time to catch up.

It's already one cycle after when these exceptions were planned to be
removed, so let's take them out now.

https://bugzilla.gnome.org/show_bug.cgi?id=697229
assert-msg-test: Explicitly quit gdb session to avoid zombie

gdb is run in batch mode, and can leave leave the program being
executed/debugged running when the batchfile is finished. Explicitly
"quit"ing the subprocess prevents it from leaving the stray subprocess
when gdb finishes.

https://bugzilla.gnome.org/show_bug.cgi?id=731366
gnextstepsettingsbackend: Use same token for function-call and its availability

Availability of the g_nextstep_settings_backend_get_type() prototype
is controlled by HAVE_COCOA in gsettingsbackendinternal.h and the
actual implemenation by OS_COCOA in Makefile.am. Therefore, the
giomodule.c call to that function should also be protected by a COCOA
token rather than an CARBON token (cocoa and carbon are independent
autoconf tests).

https://bugzilla.gnome.org/show_bug.cgi?id=731425
gparam: change value of G_PARAM_EXPLICIT_NOTIFY

GParamSpec has a possibility of user-introduced flags, and we didn't
respect that with the addition of _EXPLICIT_NOTIFY.

Change the documentation for the maximum number of user flags to 10,
just to pick a somewhat random number.  The documentation here was never
correct anyway -- it previously claimed that as many as 38 flags were
possible.

Meanwhile, move G_PARAM_EXPLICIT_NOTIFY next to _DEPRECATED in order to
avoid conflicts with low-numbered user flags (which are in use by at
least evolution-data-server).

https://bugzilla.gnome.org/show_bug.cgi?id=731341
gbookmarkfile: Cleaner error handling code to pacify static analysis

A static analyzer flagged the g_file_get_contents() call as not
checking its return value.  While the code here is actually correct,
it's verbose at best.

I think the "goto out + cleanup" code style is substantially cleaner,
less error prone, and easier to read.  It also will pacify the static
analyzer.

https://bugzilla.gnome.org/show_bug.cgi?id=731584
gparam: Remove unnecessary conditionals around preconditions

These cause a static analyzer to think we're trying to actually handle
them being NULL, which is not the case.  They both must not be NULL,
period.

No idea why the code was like this originally.

Reviewed by mclasen on IRC.