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
> No we don't need to handle a full-disk.

Remember some users store the Mixxx Settings (--settingsPath) along with the Tracks, to carry them on a jump drive. In this case the cover cache should also be there. 

> Our analysis results take a hell lot more space then the covers and when your home folder is so full that you can't even save a <100kb cover anymore you'll have other problems then running mixxx. 

There is no problem in using cover cache on the HD, if there is a valid reason. But just copy a file that is already accessible from else where seam to me not such a reason. 

> You also use banshee, they store the covers in ~/cache/media-art for my complete library that takes about 66MB.

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. 

Did you had a look at Clementine? It's cover cache is here ~/.config/Clementine/albumcovers and it stores only downloaded covers, in one size. This seams to be a good strategie.  It is worth to look also at all the features they build around covers.  

> That is not different from how we treat id3tags currently. Mixxx doesn't notice if you change them automatically the user has to manually reread them. We could to the same for covers.

Yes, cool. This would solve the issue in the Mixxx way. 

>>    ./.jpp

> what is that supposed to mean? I actually like the priority range that Marcos currently has.

Github has striked me again. Here the raw data: 
```
What about this 
1. Track cache (is only used if the user configures a different cover in Mixxx) 
2. ./<track-file-base>.jpp
3. embedded
4. cover.jpg / folder.jpg
6. anything else found in the folder 
```
Is it hard to get all the function details from the source code. Is there a design document? 

>>  It could be also interesting to specify a cover cache from an external player as cover source.

> Maybe but it shouldn't be part of this PR. It is already large enough just covering the internals. 

Yes sure, this is a corner case anyway. At least the banshee and clementine cache is useless, because of the encoded file names. This might be part of the Banshee import later.