Signed-off-by: Thomas Haller <thaller@redhat.com>

We weren't checking whether the form closed because the menu was
activated or because the user hit Escape

https://bugzilla.redhat.com/show_bug.cgi?id=1078281

GLib registers number->string value transforms (meaning that
number-valued properties like NMSettingVlan:id or NMSettingWired:mtu
get loaded into their NmtNewtEntries correctly), but not the
corresponding string->number transforms (meaning changes made in the
entries don't get propagated back to the settings, and due to
http://bugzilla.gnome.org/show_bug.cgi?id=726574, there's no warning
about this). Fix this by registering our own transforms.

If you launched nmtui directly into the editor for a specific
connection, it would hang with a blank screen when you quit.

Fix this by changing the way startup works a bit, and have the created
toplevel NmtNewtForm get returned all the way to nmtui.c, which can
then connect to the "quit" signal on it and quit (rather than having
the different subprograms trying to guess whether they're supposed to
quit-on-exit or not).

nmt_newt_listbox_clear() did not reset active and active_key, which in
the case of NmtEditConnectionList meant that after the connection list
was rebuilt, the selection would appear to be in the same place, but
active_key would still point to the connection that used to be in that
row, rather than the one currently in that row, so if you immediately
hit Edit or Delete, you'd get unexpected results. (It also meant that
it was possible for the selection to land on a header row instead of a
connection row.)

This was particularly bad in the case of the Delete button, since
active_key would be left pointing to a freed NMConnection in that
case.

Fix NmtNewtListbox, and then add code to NmtEditConnectionList to
preserve the selection itself when rebuilding the list.

After applying a configuration with static IPv4 addresses, call
/sbin/arping to announce the new addresses to the host's neighbors.
(Basic idea copied from Fedora ifup-eth.)