The band/channel property is not considered when connecting to an
access point. Print a warning, when setting one of these values in edit
mode.

For now, don't forbid the user to make such setting. Also, because in
the future, wpa_supplicant might support this.

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

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

That means you can display single property.

Example:
$ nmcli -f connection.id,802-3-ethernet.mtu s c my-eth-profile
connection.id:                          my-eth-profile
802-3-ethernet.mtu:                     auto

The format of property values that nmcli prints is not the same (for some
properties) as the format nmcli editor accepts as input from user. The reasons
are that (a) output format is more descriptive and not much suitable to be
typed, (b) it comes in most cases from libnm-util.
'change' command displays current property value and allows users to edit it.
So we convert the output into input format, before presenting it to the user.

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

nmc_setting_reset_property() function checks whether we allow changing the property
(set_func != NULL) and if so, the property value is reset to default.

The handlers detecting changes of IP addresses/method in nmcli interactive
editor were connected only for newly created connection. That's why the
automagic feature of setting 'method' when 'addresses' are changed and vice
versa worked just for new connections, but not while editing existing
connections.

Functions to
 - get property value and return it in GValue
 - set property value from GValue

nmcli connection edit [type <type>] [con-name <name>]

Examples:
nmcli c e
nmcli c e type ethernet
nmcli c e type wifi con-name "My home Wi-Fi"
nmcli c e type bond
...

It's a bit clearer to find the setting and add new ones.