Makefile.am: move gtk-doc.make back to EXTRA_DIST

0192c599377c35cc465eed1ae61de56d5a1034e8 moved this file from EXTRA_DIST TO
BUILT_EXTRA_DIST for an unknown reason.

Having it here causes the timestamp to be updated during 'make dist' to
something newer than docs/reference/*/Makefile.in.  This is a problem
because those Makefile.in are generated by including gtk-doc.make, so
automake becomes convinced that they need to be regenerated.  This is a
problem for people who don't have automake installed, or have the wrong
version.

The timestamp problem has been around for quite a while, but it only
became a problem recently after automake changed policy about this in
commit a22717dffe37f30ef2ad2c355b68c9b3b5e4b8c7.

Specifically:

https://bugzilla.gnome.org/show_bug.cgi?id=700350
GDBusConnection: remove an unused g_variant_get()

https://bugzilla.gnome.org/show_bug.cgi?id=698375
GDBusConnection: move 'Set' typecheck to worker

We presently do a lot of checks on property sets (signature check,
correct interface, property exists, etc.) from the worker thread before
dispatching the call to the user's thread.  The typecheck, however, is
saved until just before calling the user's vfunc, in their thread.

My best guess is that this was done to save having to unpack the value
from the tuple twice (since we don't unpack it until we're just about
the call the user).

This patch moves the check to the same place as all of the other checks.

The purpose of this change is to allow for sharing this check with the
(soon-to-be-introduced) case of handing property sets from
method_call().

This change has a minor side effect: error messages generated by sending
invalid values to property sets are no longer guaranteed to be correctly
ordered with respect to the void returns from successful property sets.
They will instead be correctly ordered with respect to the other error
messages.

https://bugzilla.gnome.org/show_bug.cgi?id=698375
GDBusConnection: some straight-up refactoring

Separate the code for validating a method call from the code for
actually scheduling it for dispatch.

This will allow property Get/Set/GetAll calls to be dispatched to the
method_call handler without duplicating a lot of code.

https://bugzilla.gnome.org/show_bug.cgi?id=698375
GDBusMethodInvocation: add 'property_info'

Add a field on GDBusMethodInvocation for GDBusPropertyInfo.

For now, it is always %NULL.  It will be set in future patches.

https://bugzilla.gnome.org/show_bug.cgi?id=698375
GDBusConnection: allow async property handling

The existing advice in the documentation to "simply" register the
"org.freedesktop.DBus.Properties" interface if you want to handle
properties asynchronously is pretty unreasonable.  If you want to handle
this interface you have to deal with all properties for all interfaces
on the path, and you have to do all of the checking for yourself.  You
also have to provide your own introspection data.

Introduce a new convention for dealing with properties asynchronously.

If the user provides NULL for their get_property() or set_property()
functions in the vtable and has properties registered then the
properties are sent to the method_call() handler.  We get lucky here
that this function takes an "interface_name" parameter that we can set
to "org.freedesktop.DBus.Properties".

We also do the user the favour of setting the GDBusPropertyInfo on the
GDBusMethodInvocation for their convenience (for much the same reasons
as they might want the already-available GDBusMethodInfo).

Add a testcase as well as a bunch of documentation about this new
feature.

https://bugzilla.gnome.org/show_bug.cgi?id=698375
GDBusMethodInvocation: add property return checks

Add some type checking for the values returned from async property
handling calls, similar in spirit to the type checking we do for normal
method calls.

https://bugzilla.gnome.org/show_bug.cgi?id=698375
GDBusMethodInvocation: add missing 'goto out'

We do a bunch of new validity checks for return values in response to
calls on the D-Bus property API but we miss the 'goto out' in one case.
Add it.

https://bugzilla.gnome.org/show_bug.cgi?id=698375
docs: fix GTK-Doc build

cd html && gtkdoc-mkhtml $mkhtml_options  gio ../gio-docs.xml
../xml/gdbusconnection.xml:2063: parser error : Opening and ending tag mismatch: literal line 2062 and para
</para>
       ^
Define GTESTER_REPORT for non-GLIB too
Allow registering instance private data during get_type()

For static types, it should be possible to register a private data
structure right when we are registering the type, i.e. from the
get_type() implementation. By allowing this, we can take advantage of
the existing type definition macros to cut down the amount of code
necessary (as well as the knowledge baggage) when creating a new type.

The main issue with this new feature is that it cannot be mixed with the
old idiomatic way of adding private instance data by calling a function
in the middle of the class_init() implementation, as that imposes the
additional constraint of initializing the whole type hierarchy in order
to retrieve the offset of the private data in the GTypeInstance
allocation.

For this reason we are going to follow a two-step process; in the first
step, we are going to introduce the new (semi-private) API to register
the intent to add private instance data from within the get_type()
implementation, and hide it behind a macro; at the same time, the
G_DEFINE_TYPE_EXTENDED macro is going to be modified so that it will
register the private instance data if the macro was used, using a new
(semi-private) function as well. Once we have migrated all our code, we
will make the first new function perform the actual private data
registration, and turn the second new function into a no-op. This should
guarantee a transparent migration of existing code to the new idiomatic
form.

https://bugzilla.gnome.org/show_bug.cgi?id=700035
Add G_PRIVATE_OFFSET

A macro that evaluates to the offset of a field inside an instance
private data structure.

https://bugzilla.gnome.org/show_bug.cgi?id=700035
gobject: Add private field access macros

Similar to G_STRUCT_MEMBER and G_STRUCT_MEMBER_P, but automatically using
the G_PRIVATE_OFFSET macro.

https://bugzilla.gnome.org/show_bug.cgi?id=700035
gparam: Use the new private instance data API

https://bugzilla.gnome.org/show_bug.cgi?id=700035
gio: Use the new private instance data declaration

Use the newly added macros, and remove the explicit calls to
g_type_class_add_private().

https://bugzilla.gnome.org/show_bug.cgi?id=700035
docs: Include newly added functions and macros

The functions are private, and an implementation detail of the macros.

https://bugzilla.gnome.org/show_bug.cgi?id=700035
docs: Clean up the GObject tutorial a bit

Started off by using the new instance private data macro, ended up
cleaning up the obscure, out of date, or simply broken concepts and
paragraphs.

https://bugzilla.gnome.org/show_bug.cgi?id=700035
gio: Missing G_ADD_PRIVATE in GFileInputStream
Rename the generated private data getter function

As it turns out, we have examples of internal functions called
type_name_get_private() in the wild (especially among older libraries),
so we need to use a name for the per-instance private data getter
function that hopefully won't conflict with anything.
small docs xml fixup