Cover art support

- [x] implement database scheme
- [x] search for embedded cover
- [x] search for cover in track directory
- [x] save covers in disk cache
- [x] search for covers in disk cache
- [x] minimal ui (display covers in lower left corner)
- [x] handle existing users
- [x] LRU cache
- [x] unit tests
> The only drawback is that we loose the wrapper class nature if we use QPixmapCache from everywhere.

Yeah, this is true...

>Why not "requestPixmap(trackId, coverLoc, &m_pixmap)" ?

Hmm, I'm not sure if it would work well for others widgets, because in this way we would have to store the lastrequestedpixmap... For the current widget we would store just the last one because we always display just one cover... but, would it works fine when we call it more times? what I mean is that we could have to maintain a list of "last requested pixmaps" in the widget...

What about this flow below?
``` c++
px getPixmap(trackId, coverLoc) {  // this name is not ideal
    QPixmap px;
    if (QPixmapCache::find(cover, &px))
        return px
    else
        requestPixmap(trackId, coverLoc)  // private method

    return QPixmap();
}

void requestPixmap(trackId, coverLoc) {
    // ...
    // set up the working threads
   // ...
}
void imgLoaded() {
   emit(pixmapCached(trackId))
}
void imgFound {
   emit(pixmapCached(trackId))
}
```
Maybe It's not a ideal way to do it because we would be doing two different things in ```getPixmap```...
But, I think that if the widget could get the pixmap which we have already loaded in cache, we could remove the "emit(pixmapFound)" that we have in ```requestPixmap``` and it would reduce the ```pixmapFound``` emission significantly...

Anyway, I like your suggestion of using "requestPixmap(trackId, coverLoc, &m_pixmap)", it's cleaner and it seems to sort everything out... The question is, in case of have to maintain a qpixmap list, could it be a new bottleneck?