Cover art support

- implement database scheme
- search for embedded cover
- search for cover in track directory
- save covers in disk cache
- search for covers in disk cache
- minimal ui (display covers in lower left corner)
- handle existing users
- LRU cache
>Test it, I can't see why it should be much slower. Besides it doesn't matter because we load the images asynchronous.

Yeah, you're right! It's not slower!

>actually all of that could be solved by using the database as well. I don't see any reason why we couldn't do it without. Using the in-disk cache makes the code easier in some places but that is pretty much it.

Yeah, but what about big images? I think that scaling really big images to an "satisfactory" size (and store it) would be a very good strategy for any kind of widget that we would use soon... However, I'm not sure if write extra files into track directory is a good thing...

In this way we could use disk-cache only to store:
1 - downloaded covers
2 - scaled covers
(both cases would be implemented in a next PR)

>I'm german and I use cover and folder.

Oh, but it depends on the country and the user... some countries and some users are completely disconnected from english words...
Anyway, I got your point and it's fine... what about this strategy:
``` c++
// it's not a real code
QDir dir(trackDirectory);
dir.setSorting(QDir::Size | QDir::Reversed);  // sort ascending by size
QStringList imglist = dir.entryList();
for (int i=0; i<imglist.size(); i++) {
    if imglist[i] is called (cover|folder|album|front) :
        return imglist[i];
}  
return imglist[0] // lighter image