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
>But there is still no need to copy a cover which is already accessible, from a local hard drive.

Well, it's important keep in mind that the only case which we could have an accessible cover in another place, would be around the trackDirectorySearch().

I'm almost sure that running all **SoundSource and SoundSourceProxy** stuff would be much slower than just loading it directly doing QImage(location). In this way, as we extract it in the first time, why not store it in disk and start getting it directly? it sounds as a good advantage... Also, much rarely the user will change the info into the id3tags, so I don't know if it would be a good idea being worried about extracting it all the time...

Another point is that if we have a copy of those covers in our own place, we could handle it easier. For example, we could avoid storing really big covers (big resolutions) storing it (in disk-cache) with a "enough"size to show it nicely (and I'm sure that we won't need big resolutions for that) and in this way we wouldn't be changing the original file (and also do not including new files into trackDirectory). We could also handle cases when the image is too small and cases when the image is duplicated... anyway, what I mean is that having a disk-cache is essential to embedded covers and as we need it, why don't use it to store everything? being able to handle them easier...
As @kain88-de said, I'm also sure that the size used by the disk-cache would be very small (negligible) and if a user won't be able to store about 10MB of image files... probably he won't be able to load the SO...

>>Do you mean prefer getting files named as "cover OR folder"?

> Yes, for the case of more then one picture file.

I got your point that we could analyse the filenames.
We were doing it before, however, IMHO "cover" (and "folder") might not be a common cover_name for all Mixxx users. For example, most of my covers are named as "capa" which means "cover" in my native language (portuguese) and I think that can be instinctive that users download covers and store it naming it with a word in their own language... Anyway, maybe we could think about new strategies to improve this search, but I'm not sure if just looking for "cover" and "folder" would be really efficient...