Add libsecret support

This patches add the option to use libsecret as a password storage backend in darktable. Since the gnome-keyring API has been deprecated and should be replaced by libsecret sooner or later this needs to be done in darktable. In addition kwallet already supports libsecret itself and therefore libsecret can also replace the kwallet backend implementation. Therefore this patch only enable the given gnome-keyring and kwallet backend implementation iff libsecret is not available on this system.

The first patch 3c5969b adds capability support for options in enum configuration fields which makes it possible to enable certain options in the configuration only if the corresponding capability is satisfied. This makes it possible to only show the options that actually can be used.

The second patch e5a6039 adds a new password storage backend using libsecret and depends on the first patch. It will automatically deactivate the gnome-keyring and kwallet backend if libsecret is available on the system and then only allows the user to define options that are actually available on its system in the core configuration dialog. Since attributes are not stored in an encrypted way and therefore are not part of the secret, this patch converts the passed attributes into the JSON format and stores the data as the secret in comparison to the already existing gnome-keyring backend implementation. Attributes are only used to lookup the corresponding secret item correctly. To read the encrypted attributes this patch then converts the stored JSON data into a hashtable with said attributes. For the JSON operations it uses the glib-json library that is already necessary for the implementation of picasa and facebook storage modules which rely on the password storage backend implementation.
You probably should 'g_free(label);' here? The libsecret docs are not saying that it is freeing that for you. Same for secret_value and secret_attributes I guess.