Fix GVariantBuilder leaks

Fix GVariantBuilder leaks

When using g_variant_builder_new(), we must call
g_variant_builder_unref() to free it:
"You should call g_variant_builder_unref() on the return value when it
is no longer needed. The memory will not be automatically freed by any
other call.

In most cases it is easier to place a GVariantBuilder directly on the
stack of the calling function and initialise it with
g_variant_builder_init()."

One of these leaks showed up in valgrind as:
==20702== 16,416 bytes in 114 blocks are definitely lost in loss record 2,114 of 2,115
==20702==    at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20702==    by 0x56EDDF2: g_malloc (gmem.c:97)
==20702==    by 0x570691C: g_slice_alloc (gslice.c:1007)
==20702==    by 0x5729743: g_variant_builder_new (gvariant.c:3169)
==20702==    by 0x40297B: ibus_config_dconf_get_values (config.c:413)
==20702==    by 0x4E44FF2: ibus_config_service_service_method_call (ibusconfigservice.c:214)
==20702==    by 0x4E33249: ibus_service_service_method_call_cb (ibusservice.c:395)
==20702==    by 0x51880D8: call_in_idle_cb (gdbusconnection.c:4875)
==20702==    by 0x56E81D7: g_idle_dispatch (gmain.c:5319)
==20702==    by 0x56E58F1: g_main_dispatch (gmain.c:3064)
==20702==    by 0x56E6667: g_main_context_dispatch (gmain.c:3663)
==20702==    by 0x56E6859: g_main_context_iterate (gmain.c:3734)

BUG=http://code.google.com/p/ibus/issues/detail?id=1712

[Peng, 2014-06-05 14:31:02]

thanks for fixing. LGTM