remove icons from wcoverartmenu actions
Merge pull request #11 from kain88-de/coverArt_removeIcons

remove icons from wcoverartmenu actions
add show/hide images again + update mixxx.qrc
REF: cover-widget only rely on signals

the coverArt-widget is only using the signal interface of the
coverArtCache. This commit also will let the old cover be displayed
until the cache reports back from the request.
REF: write string directly into tr call and remove &

We try do avoid formatting symbols like the ampersand for strings that
have to be translated. This also removes a memory leak because the char*
string were not being deleted with the coverartmenu widget.
coverartcache does not deliver TIO's

CoverArtCache is only responsible for handling covers. If a class wants
to have access to TIO's from the database it should get a private
reference to trackDAO.
use private member for code readability
coverart menu does not show the fullsize image

While the coverart menu is a good idea to avoid code duplication we
should let the class using it decide if they want to offer a fullsize
view. We can then implement it in a more common way. Like double
clicking a cover.
fix trailing whitespace
don't look up MD5 hash from DB, always save found cover

The MD5 hash that we request will always differ from the one that is
found because we only invoke 'searchImage' when there is no coverID set
or it points to the defaultCover. This also removes the newImageFound
variable from FutureResult.
Make cover in dlgtrackinfo work with cancel

We want that changes to the cover in dlgtrackinfo behave similar to
changing other values of the track. This required me to rework how
WCoverArtMenu works. WCoverArtMenu is now only a common menu that DOES
NOT CHANGE the database instead the widget implementing the menu does
this now when it sees fit. Another important change to make this work is
that 'CoverArtCache::searchImage' can now be called from any class
without the need use 'requestCover'. This is necessary to reload the
cover from the ID3tags/folder without updating the DB. This is ok in
this case because we only search for 1 cover and we will only block the
UI thread for a fraction of a second. I also think this is ok in this
special case because changing covers won't happen very often and a user
will to this one track at a time anyway, while the normal cover display
requires us to provides covers for several tracks simultaneously.