libnm: add generic-data for implementing NMSetting

Currently, most NMSetting implementations realize all their propertiesvia 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 originalvariant. 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.