Although the commit is not huge, some extra bits of information might
be useful as documentation. Bear with me :)

Internally, all metadata-keys are handled with the use of
GrlRelatedKeys as that object handles (better) the actual value of
each metadata-key.

In GrlData, prior to this patch, all GrlRelatedKeys were handled in a
unique GHashTable with metadata-key as Key and a GList of
GrlReatedKeys as Value.

Handling GrlRelatedKeys added by the user together data added with
grl_data_add_* and grl_media_add_* APIs is error prone.  The
`test_compat_of_metadata_keys_with_related_keys` unit test in
test/media.c gives a small sample of that.

With this patch, the internal organization of GrlRelatedKeys is now
split in:

 * GHashTable for 'single' metadata-keys (Single as in `there is no
   relation to another metadata-key`);

 * GList for 'groups' of metadata-keys.

I've chosen to work with a list of all GrlRelatedKeys to simplify
handling the use case that the current API supports, which is Set of
metadata-keys. Handling a more complex use case, like different type
of Sets, would need a different data struct if we are targeting more
optimized code. To work on that, better is to wait an actual use case.

You will see with the removal of the helper function get_sample_key()
that we are no longer looking into the bind-key for a given
GrlRelatedKey. This is on purpose. The following up patches moves
towards deprecation of preconfigured relation between metadata-keys.

The TL;DR for Grilo users is:

* Use GrlMedia and GrlData APIs to add values to your metadata-keys.
* GrlRelatedKeys APIs are meant to handle Group of metadata-keys

Related: GNOME/grilo#145