When trying to run xfwm4-settings 4.12 without xconfd installed this segfault always happen.

Here is a backtrace:

```
#0  0x000055555555cc8c in xfwm_settings_button_layout_property_changed (channel=<optimized out>, property=0x55555555dbcd "/general/button_layout", settings=<optimized out>, 
    value=0x7fffffffd880) at xfwm4-settings.c:1397
#1  xfwm_settings_constructed (object=<optimized out>) at xfwm4-settings.c:501
#2  0x00007ffff6a653d0 in g_object_new_internal (class=class@entry=0x5555558f30f0, params=params@entry=0x7fffffffdaa0, n_params=n_params@entry=1) at gobject.c:1837
#3  0x00007ffff6a6713e in g_object_new_valist (object_type=<optimized out>, first_property_name=<optimized out>, var_args=var_args@entry=0x7fffffffdbf0) at gobject.c:2120
#4  0x00007ffff6a674b9 in g_object_new (object_type=<optimized out>, first_property_name=<optimized out>) at gobject.c:1640
#5  0x0000555555559315 in main (argc=<optimized out>, argv=<optimized out>) at xfwm4-settings.c:931
```

Upon quick inspection of the source code I see that the immediate problem is *not* checking the return status of `xfconf_channel_get_property()`, which sadly seems to be a coding convention across the codebase there, but then happily acting upon its result value. The same then applies inside `xfwm_settings_button_layout_property_changed()`:

```
for (str_value = g_value_get_string (value); *str_value != '\0'; ++str_value)
```

again, *not* checking the return value of `g_value_get_string()`, but happily de-referencing it, which has been causing the segfault. This was fixed 10 months ago in https://git.xfce.org/xfce/xfwm4/commit/?id=5ece9b89905cfa65023f00b8e185fbf438c076f8, however, so it no longer crashes, instead the critical Glib assertion is still triggered and all configuration changes are silently ignored (tested on 4.14).

`xfconf_channel_get_property()` fails, because it cannot communicate with xconfd via dbus. This case should be handled gracefully instead of failing miserably or being silently ignored.