Add a new way how NMSetting subclasses can be implemented.

Currently, most NMSetting implementations realize all their properties
via GObject properties. That has some downsides:

 - the biggest one, is the large effort to add new properties.
   Most of them are implemented on a one-by-one basis and they come
   with additional API (like native getter functions).
   It makes it cumbersome to add more properties.

 - for certain properties, it's hard to encode them entirely in
   a GObject property. That results in unusable API like
   NM_SETTING_IP_CONFIG_ADDRESSES, NM_SETTING_BOND_OPTIONS,
   NM_SETTING_USER_DATA. These complex valued properties only
   exist, because we currently always need GObject properties
   to even implement simple functionality. For example,
   nm_setting_duplicate() is entirely implemented via
   nm_setting_enumerate_values(), which can only iterate
   GObject properies. There is no reason why this is necessary.
   Note also how nmcli badly handles bond options and VPN
   data. That is only a shortcoming of nmcli and wouldn't
   need to be that way. But it happend, because we didn't
   keep an open mind that settings might be more than just
   accessing GObject properties.

 - a major point of NMSetting is to convert to/from a GVariant
   from the D-Bus API. As NMSetting needs to squeeze all values
   into the static GObject structure, there is no place to
   encode invalid or unknown properties. Optimally,
   _nm_setting_new_from_dbus() does not loose any information
   and a subsequent _nm_setting_to_dbus() can restore the original
   variant. That is interesting, because we want that an older
   libnm client can talk to a newer NetworkManager version. The
   client needs to handle unknown properties gracefully to stay
   forward compatible. However, it also should not just drop the
   properties on the floor.
   Note however, optimally we want that nm_setting_verify() still
   can reject settings that have such unknown/invalid values. So,
   it should be possible to create an NMSetting instance without
   error or loosing information. But verify() should be usable to
   identify such settings as invalid.

They also have a few upsides.

 - libnm is heavily oriented around GObject. So, we generate
   our nm-settings manual based on the gtk-doc. Note however,
   how we fail to generate a useful manual for bond.options.
   Also note, that there is no reason we couldn't generate
   great documentation, even if the properties are not GObject
   properties.

 - GObject properties do give some functionality like meta-data,
   data binding and notification. However, the meta-data is not
   sufficient on its own. Note how keyfile and nmcli need extensive
   descriptor tables on top of GObject properties, to make this
   useful. Note how GObject notifications for NMSetting instances
   are usually not useful, aside for data binding like nmtui does.

Also note how NMSettingBond already follows a different paradigm
than using GObject properties. Nowdays, NMSettingBond is considered
a mistake (related bug rh#1032808). Many ideas of NMSettingBond
are flawed, like exposing an inferiour API that reduces everything
to a string hash. Also, it only implemented the options hash inside
NMSettingBond. That means, if we would consider this a good style,
we would have to duplicate this approach in each new setting
implementation.

Add a new style to track data for NMSetting subclasses. It keeps
an internal hash table with all GVariant properies. Also, the
functionality is hooked into NMSetting base class, so all future
subclasses that follow this way, can benefit from this. This approach
has a few similiarties with NMSettingBond, but avoids its flaws.

With this, we also no longer need GObject properties (if we would
also implement generating useful documentation based on non-gkt-doc).
They may be added as accessors if they are useful, but there is no
need for them.

Also, handling the properties as a hash of variants invites for a
more generic approach when handling them. While we still could add
accessors that operate on a one-by-one bases, this leads to a more
generic usage where we apply common functionality to a set of properties.

Also, this is for the moment entirely internal and an implementation
detail. It's entirely up to the NMSetting subclass to make use of this
new style. Also, there are little hooks for the subclass available.
If they turn out to be necessary, they might be added. However, for
the moment, the functionality is restricted to what is useful and
necessary.