On (not so) large music collections, having this option present and
selected by default brings in a widget count explosion, making the UI look
slow on scrolling, or operations involving forall() on containers, like
style changes when focusing/unfocusing the window.

Furthermore, grilo operations are not cancelled when selecting another
artist from the list on the left, so items won't be populated until the
"all artists" queries have finished. This means the user still has to
wait for that operation to finish regardless of selecting an specific
artist.

Just avoid this by removing the "All artists" option, even if less neat
looking, the "Albums" view already offers a global view. This involves
significantly less grilo/tracker queries and widgets on the window
happening by default on the "Artists" view.

Blacklisting has moved to finish(), which has been ensured to be called
on all error paths. items are also checked early in the blacklist on the
lookup process.

This, most notably, ensures we don't continuously spawn threads to look
up items that previously failed, the worker/download threads will be
spawn just once for each of these.

AlbumWidget and ArtistAlbumWidget have been updated to rely on discovery
from the Player object, this means we can avoid performing discovery on
the add_item() functions.

As a side effect, the views have been updated to rely on DiscoveryStatus
from the model in order to control the visibility of the error icon, this
means the pixbuf and "icon visible" columns from the model are now unused.

All ViewContainer subclasses have been updated to rely on discovery from
the player object, this means we can avoid performing discovery on the
various add_new_item() functions.

As a side effect, in order to show the proper error icon on songs that
can't be played, the pixbuf cell renderer management is now done on a
cell data func that uses the DiscoveryStatus to update the cell renderer
accordingly, this means the pixbuf and icon visible columns in the models
are now unused.

All models have been added a column to store the DiscoveryStatus for the
song, and this column is passed on set_playlist(), so the Player object
does take care of updating the status after the song failed playing, or
discovery failed on it.

This makes sure we react properly to player/discovery failures for the
current and next songs, and only when it's needed so. Discovery is a
very expensive operation, and this allows us to stop doing it for every
song at the time of adding these to a model/view, which means lots of
I/O and CPU time just to know whether songs can be played, even it they
might not eventually.

This also moves star renderer to widgets.py where it belongs

'favorites' playlist added

favorites are starred in 'songs' and 'playlists' views.

(currently super hacky, storing favorite data as 'lyrics'. should update to storing in 'favourite' asap.)

add/remove favorite queries

view: make star renderer togglable

view: ugly solution to skip on_item_activated if we clicked on start cellrenderer

changed Tracker.SparqlConnection object to singleton (within TrackerWrapper)

prelim. toggle_favorite func (not yet called)

toggle favorite status in database when toggling star in Songs view

added togglable stars to playlists view

changed add/rm favorites to rely on song urls, not ids

https://bugzilla.gnome.org/show_bug.cgi?id=743901

https://bugzilla.gnome.org/show_bug.cgi?id=743310

https://bugzilla.gnome.org/show_bug.cgi?id=743310

static playlists now update from player.py at time of scrobble rather than from playlists.update_playcount

https://bugzilla.gnome.org/show_bug.cgi?id=743310

https://bugzilla.gnome.org/show_bug.cgi?id=743310

https://bugzilla.gnome.org/show_bug.cgi?id=729376