So the logic to avoid encoding ':' when part of a drive letter can kick
in

This actually adds tests for toMrl, which were missing before.

This is currently not supported for the vmem thumbnailer though.

Fix #99

Whether we're using libvlc or not is irrelevent for this case.

closes #98

Now that we can get the thumbnail path based on the thumbnail id alone,
we don't have to fiddle with what kind of entity was removed

This is possible now that we always create a failure record before
starting the generation.
It's more deterministic since we now always know the thumbnail's path
for sure, as it's linked 1:1 with the database entry

refs #98

refs #98

Otherwise the information gets lost, and there's no way for the user to
know which size got generated.

refs #98

Even if a thumbnail was generated before, so as to allow the users to
update the thumbnails based on the playback progress
refs #98

refs #98

refs #98

Media, Album & Artist can now have multiple thumbnail, of different size
types.
This rollbacks the previous changes of model version 17, which is only
used in the iOS beta for now.
refs #98

Pass the (hardcoded, for now) values to the Task constructor
Refs #88

There is no guaranty that we will have a thumbnail to link.

So it doesn't conflict with the thumbnail() member function

Instead of fetching them all only to count the number of results.
It will soon be impossible to fetch the thumbnail independently of their
associated entities
refs #98

We must mark the thumbnail as not owned, otherwise the "relative path"
logic kicks in, and we end up with a non empty mrl.

The mrl is enough, now that we also provide the destination path

As it is unused

As we will soon need more than just a media.
Refs #98

We now flush the thumbnails as well when doing a rescan, so there is no
need to migrate those anymore