core: improve handling of POSIX signals using sigwait() (rh #739836)

There are multiple ways how to handle standard unix signals. They work quite
well for a single-threaded application. However, signal handling in a multi-
threaded app becomes tricky. And, the most safe way is to use sigwait() function
in a dedicated thread, which allows us to process the signals synchronously and
thus avoid various nasty problems.

A few useful links:
http://pubs.opengroup.org/onlinepubs/007904975/functions/sigwait.html
http://pic.dhe.ibm.com/infocenter/aix/v6r1/index.jsp?topic=%2Fcom.ibm.aix.genprogc%2Fdoc%2Fgenprogc%2Fsignal_mgmt.htm
http://www.linuxjournal.com/article/2121?page=0,2
http://www.redwoodsoft.com/~dru/unixbook/book.chinaunix.net/special/ebook/addisonWesley/APUE2/0201433079/ch12lev1sec8.html
core: don't fight with the kernel over the default IPv6 route

The kernel wants there to be a default route over every RA-ed IPv6
interface, and it gets confused and annoyed if we remove that default
route and replace it with our own (causing it to effectively drop all
further RAs on the floor, which is particularly bad if some of the
information in the earlier RA had an expiration time).

So, rather than replacing the kernel's default route(s), just add an
additional one of our own, with a lower (ie, higher priority) metric.

https://bugzilla.redhat.com/show_bug.cgi?id=785772
trivial: fix spacing
libnm-glib: ensure NMRemoteConnection signals are disconnected (bgo #674484) (lp:949743)

If a client keeps the connection around after NMRemoteSettings is done
with it (and has emitted 'removed' for that connection) then the
RemoteSettings object was still registered to receive signals for
that connection.  To prevent clients from being able to screw up
the RemoteSettings, disconnect any signals it may be listening for
when the connection is removed.  (it should be doing that anyway)
libnm-glib: protect against potentially NULL changed property values (rh #808784)

No idea *why* they're NULL, unless perhaps that dbus-glib can't demarshal
the variants for some reason, but until we know why at least log the
problem so we know what properties the issue might affect.
libnm-glib: NULL out priv fields on dispose()

In some situations, objects might get used after being disposed, so
clear out their various priv fields so we don't try to access unreffed
objects, freed strings, etc.

https://bugzilla.gnome.org/show_bug.cgi?id=674473
libnm-glib: discard devices and active connections when NM goes down

When NMClient changes state to "not running", don't just unref all the
devices and connections: emit notify::active-connections and
device-removed signals too, so the app will drop its copies of them.

https://bugzilla.gnome.org/show_bug.cgi?id=674473
libnm-glib: ensure object cache is cleared when NM stops (bgo #674473)

Otherwise if a client holds references to the objects (or in the
JavaScript case, uses deferred garbage collection) they'll still
be in the cache when NM restarts, and the old object may have the
same path as some new object, which isn't good.
build: report whether WEXT is enabled or not (bgo #674650)
core: notify that "active-connection" property changed on NMDevice

This is necessary so that PropertiesChanged D-Bus signal is properly
issued.
libnm-glib: add "object-creation-failed" signal to NMObject

The signal is private for libnm-glib and should not be used externally.
It is emitted when there's an error while creating an object.
In addition, this commit makes use of the signal in NMClient to ensure
that the callbacks are always called for nm_client_activate_connection()
and nm_client_add_and_activate_connection().
ifcfg-rh: fix vlan DEVICE parsing

A vlan DEVICE name must be either $(OTHERDEVICE).$(VLAN_ID) or
vlan$(VLAN_ID). Enforce that. In particular, don't:
(a) crash if the name has no "." and doesn't start with "vlan",
(b) loop forever if the $(VLAN_ID) part is non-numeric, or
(c) silently ignore non-numberic characters after the $(VLAN_ID).
core: replace strcpy() with g_strlcpy()

When copying device names into ioctl structs, we know that the device
names are of valid length, so we were using strcpy(). But you can't
prove that they're short enough just looking at the local code, so
some code analysis tools warn about a potential buffer overflow.. So
use g_strlcpy() instead.
core: log whether WEXT is enabled or not (bgo #674650)

Now that we've encountered this twice with distros disabling WEXT
but apparently not realizing it kills staging and out-of-kernel
drivers like wl.o, make it a log message so we don't have to go
hunting for build-time logfiles.
libnm-glib: fix build on older glib without g_clear_object()
po: updated Lithuanian translation (bgo #675020)
core: ensure carrier is always on for devices that don't support detection (rh #816719)

We broke this when splitting NMDeviceWired out of NMDeviceEthernet.
cli: add 'connect to SSID' feature: nmcli dev wifi connect <SSID> ...

This is similar to clicking a Wi-Fi network's SSID in a GUI applet.
The command does this:
- creates new connection (fills the user data specified via options, the
  connection is then completed with default parameters by NM)
- and then activates the connection on a Wi-Fi device.

WPA-Enterprise is not supported as it requires a plethora of parameters and
they can't be obtained automatically.
Also, the created connection uses 'auto' IP method, which means that if the
Wi-Fi network doesn't support DHCP, the connection will albeit be created,
however the activation will fail (IP configuration won't be available).
cli: trivial, fix up spacing
man: make nmcli man page more readable

There are a few changes making the text less awkward after a native speaker's
proofreading.