GSettings

PR to better track and discuss the branch.

@Teknocrat What do you mean with "setup auto install for xml files"?

https://github.com/blueman-project/blueman/pull/101#commitcomment-7896287
@infirit I'm not sure if a migration system is worth the effort. Users would have to setup their devices again and maybe check one or the other box if they want to change the default settings. I think that doesn't hurt.

https://github.com/blueman-project/blueman/pull/101#issuecomment-56591833
@infirit The config plugin system can definitely be dropped with this change. It made some sense to provide the file fallback for the gconf default, but GSettings should be our only backend in the future and thus we don't need plugins. I'm not sure if it makes sense to keep the configuration in a dedicated class over using `Gio.Settings` directly. @Teknocrat What do you think? Is the `GSettings` class useful? It indeed looks like a rather dumb wrapper only forwarding some methods and a signal.


Off topic: https://github.com/blueman-project/blueman/pull/101#commitcomment-7896459
@Teknocrat You say, you're currently using the file storage backend. Are you absolutely sure? As I mention in #35 blueman segfaults if the gconf introspection library is missing. And looking at [Debian 762526](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762526) it seems like the Config class will always use gconf since no import error is raised when loading it and will fail if gconf is not actually available as soon as it is used. So I think currently the file backend cannot be reached! This is exactly what raised my priority for the gsettings migration.