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
>If a folder contains a "cover.jpg" it is copied to the cache if it found the first time. 
>If the user exchanges the cover, Mixxx is still displaying the cover in the cache.

Yes, but it has some advantages as well... because in this way Mixxx will prefer always getting a "ready cover" instead of looking for new ones all the time... For this first PR we didn't implement the "cover edition/update" part, but our main concept is:
1 - try loading the most covers as possible and doing it as fast as possible.
2 - If the user is not happy with the current cover that we're showing... he just need to edit it, as occur in other softwares...

> I just had a look at this folder. It seams that Banshee uses it to save pre-scaled version in this folder. In the
> current version of this PR, you scale the cover on the fly on each view-change. Will this be an issue for really big
> covers? 
> What best in performance: HD access vs. CPU Time for scaling? This could be a exiting test.

Actually I discussed about the scaling stuff with @kain88-de in initial implementations... The point is that it depends on the widget. What I mean is that each one would have a specific way to load/show the covers and also would use a different size for them...
I'm almost sure that if we start showing covers in the tableview (as in tracktor), we would be loading dozens of covers at the same time and if all of them have a really big size, it would be very slow to get them... But, IMHO as it will depends on the widget, it's the kind of thing that we could discuss in the end of this project (afterORwhile implement the final widget)...

> 1 Track cache (is only used if the user configures a different cover in Mixxx) 
> 2 ./<track-file-base>.jpp

Sorry, but I also didn't get your points.

> 3 embedded

Do you mean read id3tag directly from file (always)?

>4 cover.jpg / folder.jpg

Do you mean prefer getting files named as "cover OR folder"?
If your answer is YES... We were doing it before that 74c80e95e97929614091b78ae95e3a6b73646795
The point is that it's not a strong rule. What I mean is that each user could have a different way to call their covers and the user language would affect as well. So, we would have a algorithm which would be efficient just for a group of users (maybe English speakers)...


>Is it hard to get all the function details from the source code. Is there a design document?

Oh, maybe you noticed that we did a lot of refactoring so far, and it would be hard to have a updated document in this way because it would take a lot of time... I have plans to document everything, but I don't like the idea of doing it when I'm just testing things...
Anyway, I know that it's a big PR and it would be nice if you could have just a simply flowchart just to know how everything is linked... I can do it using draw.io and sharing it with you (if you want). Could you give me your email, please?