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
> 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...

Yes, the strategy sound good. It is all like the current reload metadata function. I did not propose to search for covers all the time, searching for covers one time and store the result in the database is fine. 
But there is still no need to copy a cover which is already accessible, from a local hard drive.
Did you check the Clementine approach?    

> 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)...

I also do not like the solution of storing rescaled covers on the HD. You may consider to cache them in ram rather than the original size, which is only displayed in rar conditions.
For future covers within the library tables, I would not brood to much. If we load them with a reasonable delay in a background thread it would be fine. Remember that we have two real time tasks, (Audio and Waveform) so it is in general a bad idea focusing on cover load speed only.  



>>    1 Track cache (is only used if the user configures a different cover in Mixxx)
>>    2 ./.jpp

> Sorry, but I also didn't get your points.

Does this help now? 
What about this reworked one 
```
1. Path in DB, found on a previous scan or set by the user. This might point to a downloaded file in track cache folder or to any other local URL  
2. <track-file-base>.jpp in the track directory for <track-file-base>.mp3
3. embedded in file metadata
4. cover.jpg / folder.jpg
6. anything else found in the folder 
```

>> 3 embedded

> Do you mean read id3tag directly from file (always)?

Yes. It looks like Clementine does it like that. What could be a drawback? 
From the theory there should be no difference between loading a plain cover at offset 0 or reading it form a specific offset inside a audio track.   


>>  4 cover.jpg / folder.jpg

> Do you mean prefer getting files named as "cover OR folder"?

Yes, for the case of more then one picture file. 

I am not sure, but it looks like Windows uses the folder.jpg as default folder cover.
http://forum.team-mediaportal.com/threads/script-to-automatically-create-folder-jpg-images-for-your-series.116018/

As far as I know, Winamp has introduced the cover.jpeg and Clementine takes this default as well.
Here the Winamp rules:
http://forums.winamp.com/showthread.php?t=371985

> 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)...

Yes no strong rule, but best practice of almost all media-players. So Mixxx should follow.  

> 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?

I do not need a flow chart. I am able to read code;-). 
It would be nice if some critical things like the DB schema, cache strategy and load priority would be outlined in a wiki page for later reference. This could be also the base for the user manual. Discussing it before coding will save you from some extra work, by the way.