core: fix a spurious warning with non-kernel network devices

NMDevice was warning about not being able to set ifindex even on
devices that we know don't have an ifindex.

https://bugzilla.gnome.org/show_bug.cgi?id=739889
docs: make the settings docs work from tarball builds

docs/api/settings-spec.xml was accidentally not getting disted,
because gtk-doc.make explicitly removes all DISTCLEANFILES from
distdir. However, it doesn't actually make sense for the settings docs
files to be in DISTCLEANFILES anyway; they were put there rather than
CLEANFILES (IIRC) so that "make clean" in a tarball build wouldn't
delete them and break things. But the right fix is to just make them
only be in CLEANFILES when BUILD_SETTING_DOCS is true, and not ever
get deleted otherwise.

Also adjust the build rules to ensure that the generated docs don't
get rebuilt in tarball builds, since that can cause problems when
building from a read-only source tree, etc.

Meanwhile, in an unrelated but also fatal bug, configure.ac's check
for if the generated docs were already present never got updated for
the cli/src -> clients/cli move, and so even if we had been disting
settings-spec.xml, configure would still think that the tarball didn't
have all of the generated docs in it, so SETTING_DOCS_AVAILABLE would
be set false and none of the generated docs would get used.

https://bugzilla.gnome.org/show_bug.cgi?id=740035
core: fix return type of addrconf6_start()

It returned a boolean and the caller expected a boolean, but the
return type was NMActStageReturn.
libnm: Watch for AC removal in case of AddAndActivateConnection() as well

This does the very same thing as 42b9e8283 does for plain ActivateConnection().
cli: Finish waiting for the device activation when it disconnects

The device status alone is uninteresting as its changes can be due to
deactivation of previously active connection. We should monitor the
active connection changes instead of device state changes.

However the device state changes is still interesting, as it contains the
reason for the change, let's just ignore them while the connection is
activating.

Lastly, we need to handle failures as well. It should be noted that it's
not sufficient to deal with NM_DEVICE_STATE_FAILED as the device will
quickly draverse to NM_DEVICE_STATE_DISCONNECTED. This happens in case of
a failure due to NM_DEVICE_STATE_REASON_NO_SECRETS as soon as the server
makes sure it won't reconnect automatically.
merge: nmcli device activation behavior fixes (bgo #740136)
libnm: add some missing (transfer) annotations

All the old "const GByteArray" methods got changed to return a GBytes
instead, but since they aren't declared "const" any more, we need to
explicitly annotate them "(transfer none)".

Also, the scanner apparently doesn't recognize that an (out)
"const char **" is "(transfer none)", so annotate that in two places
too
libnm-core: add some missing array length annotations

A bunch of nm-utils methods that used to take GByteArray now take
array+length, but weren't annotated to indicate that.
examples: update python examples

Update the raw D-Bus python examples to use newer APIs where
appropriate (and split the add-connection example into 1.0-only and
0.9-compatible versions). Update the gi-based python examples for the
various API changes since they were last updated.

Also add a comment to the ruby add-connection example pointing out
that it's still using the old settings APIs.
libnm, examples: fix some annotations and update python examples (bgo 740145)
libnm-core: add _nm_utils_is_manager_process

Add a variable indicating whether the process is the NetworkManager
daemon.
libnm-core: change how new and legacy properties are serialized

Although libnm filters out properties received from the daemon that it
doesn't understand, there may be other clients that do not. In
particular, a client might call GetSettings() on a connection, update
the ipv4.addresses property in the returned dictionary, and then pass
the dictionary to Update(). In that case, the updated dictionary would
contain ipv4.address-data, but it would not reflect the changes the
client intended to make.

Fix this by changing the daemon side to prefer the legacy properties
to the new ones if both are set, and changing the client side to not
send the legacy properties (since we don't support new clients talking
to old servers anyway).
libnm-core: change how new and legacy properties are serialized (bgo 740140)