freebase: reader_fill_object_gvalue() is only meant for "object" types

Compound types are only meant to be handled through
reader_fill_compound_gvalue(), which will iterate through its "property"
array. Otherwise, compound elements with an ID (which is not mandatory,
but ok for these to have) would be created as shallow objects instead
of containers of further objects/values.

https://bugzilla.gnome.org/show_bug.cgi?id=737539
freebase: Fix thinko when creating compound GDataFreebaseTopicObjects

The check was actually inverted, receiving a newly created object is
obviously the expected condition. This made the parsing of compound
objects a lot more shallower than the received data.

https://bugzilla.gnome.org/show_bug.cgi?id=737539
tests: Add tests for freebase topic API

https://bugzilla.gnome.org/show_bug.cgi?id=737539
freebase: Add GType for GDataFreebaseSearchResultItem

Making it a boxed type makes it friendly to bindings, as there's
some more embedded knowledge about how to deal with this type
memory-wise.

https://bugzilla.gnome.org/show_bug.cgi?id=737936
freebase: Create async topic replies with the correct GType

The async version was wrongly using the parent type, so the returned object
wasn't a GDataFreebaseTopicResult at all.

https://bugzilla.gnome.org/show_bug.cgi?id=737540
freebase: Fix typo in search query

The string array matches the GDataFreebaseSearchFilterType, using the
FilterNodeType was unintended, and TYPE_CONTAINER happened to match
GDATA_FREEBASE_SEARCH_FILTER_ALL.

https://bugzilla.gnome.org/show_bug.cgi?id=737541
freebase: Fix locale-dependent issues in geolocated queries

Latitude/longitude are really expected with a '.' decimal point by the
service, breaking on locales that would use anything different. Use
g_ascii_formatd which always uses the '.' decimal point.

https://bugzilla.gnome.org/show_bug.cgi?id=737541
tests: Add tests for Freebase search API

https://bugzilla.gnome.org/show_bug.cgi?id=737541