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
>>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.

planned to do in the next PR

>>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.

again for me this is negligible compared to the amount of data we store for the analysis. Plus If you drive is about 99% full you will experience problems anyway, you should avoid to fill up a partition to more then 90% as a rule of thumb, I forgot from where I have that information but filesystems tend to have problems if there is no space left.

>What best in performance: HD access vs. CPU Time for scaling? This could be a exiting test.

I haven't tested CPU scaling times only HD access, The code is here
https://drive.google.com/folderview?id=0B7hW1RAtl0zUUmFKd2E5b2hJVFU&usp=sharing

```
Results with a HDD
----------------------------
load jpeg into QPixmap 
mean: 4688.57 mus	std: 7236.26 mus 
loading QImage 
mean: 4598.11 mus	std: 7030.88 mus 
converting to QPixmap from QImage 
mean: 3.49925 mus	std: 60.1218 mus 
```

> `./<track-file-base>.jpg`

I still have no clue what that should tell me.

> Is it hard to get all the function details from the source code. Is there a design document?

None that Marcos had shared with me. He went straight to implement his ideas.