bz19831: disable menu items when no downloads are selected
Don't display removed items in the library tabs
bz19823: fixed ItemTracker code for a corner case.

Here's what seems to be happening:

 - I would delete an item that was playing.
 - The backend would update the play_count variable and send an ItemsChanged
   to the frontend
 - Before that message got to the frontend, it would remove the item from the
   DB and send a second ItemsChanged
 - The frontend would call connection.commit() to try to see the changes for
   the first message, but this would move the transaction past the second
   change as well and now the item is deleted from the database, but
   ItemTracker wasn't prepared for that
 - OSX would ask for the row for the item and we would crash.

Added a test and a fix for this.  The fix isn't pretty, but I tihnk it should
do the job.  Added some code so that we would fails earlier in the process if
a similar error happens.
More correct fix for #19823

The last fix assumed that the removed item was one of the changed items, but
that doesn't have to be true.

The new approach uses 2 sql statements to check if items have been added, but
both should be very quick.
Better logging in httpclient
bz19864: display queued downloads on the downloads tab
bz19852: fix playback on windows
Avoid calling startup.initialize() twice.

This prevents us from duplicating the logging output.
bz19866: more fixes for ItemTracker crashes

Fixed it so that we open a transaction before running our initial query for
ItemTracker.  I thought that this was implicitly opened, but I guess not.

Made it so that when connections are released we close any open transaction
by rolling it back.

Emit the will-change signal on ItemTracker before we call
ItemFetcher.refresh_items().
bz19507: Don't put metadata objects into the cache if the insert fails
bz19882: Remove extraneous logging