Initial code for frontend data speedups.

Added a package called "miro.data" which the frontend will use to fetch its
data.  I choose a generic name because, who knows, maybe the backend will want
to use this too.

Added the ItemTracker class.  It uses SQL to track changes to an item list.
Added some basic tests for it.
Initial code for ItemList

ItemList takes ItemTracker and adds widgets-specific functionality.  Right now
the code layout is a bit of a mess.  The plan is to:

  - Remove the itemlist and itemtrack module
  - Replace itemlist with newitemlist
  - Refactor the itemfilter module to remove the filter() implementations that
    aren't used anymore
  - Keep the new itemsort module

it lives in the newitemlist module, but the plan is to eventually replace
miro.frontends.widgets.itemlist and miro.fronends.widgets.itemtrack module
with this new code
Attach a DB to store temporary info.

Before we had a system where we would update the RemoteDownloader objects
in-memory and only save the data every X second or so.  This won't work if the
frontend needs to query that data using sqlite.

Instead, we can create a table with journal_mode=MEMORY and synchronous=OFF.
This should make it very fast, so it should be a reasonable replacement for
the old system.
Ensure that the DB transaction is finished before emitting ItemChanges

Before both LiveStorage and ItemChangeTracker connected to the
eventloop-finished signal.  However, to make things work right we need to
ensure that the ItemChangeTracker code runs after LiveStorage commits its
transaction.  There was no guarentee that that was happening before.

Changed it so that LiveStorage emits a signal when it's done with its
transaction and made ItemChangeTracker connect to that.
Sort/filter using the remote_downloader and dlstats table in ItemTracker

Added code to populate the dlstats table when we get updates from the
downloader.

Added code to tell when we need to reload the list for ItemLists that sort on
downloader / dlstats columns.  Since this is basically all the time that the
downloader changes, we just use a flag rather than figuring out which columns
actually changed.
Worked on frontend using the items that ItemTracker outputs.

Made an new ItemInfo class that uses data directly from the DB.  I tried to
keep the old API as much as possible, but changed it in a couple of places.

Added a unittest to check that itemrenderer module doesn't throw an error when
using the new ItemInfo.

Reduced the number of items we fetch in one chunk.  After writing this class,
I realized that we need many joins to generate an item, so I think it makes
sense to not try to make so many at one time.
Modified itemlist module so that we can share ItemList objects

This is to handle the situation where the playback code and the
ItemListController are working on the same tab.  For example, I play an item,
switch tabs, then switch back tabs.  At that point, we want the
ItemListController and the playback code to share the same ItemList.  This is
good because:

- We don't have to process the ItemsChanged message twice.
- If a user changes the filters, the search, etc, the changes will be
  reflected in the playback.

Created an ItemListPool class to handle this.  It also handles calling
on_items_changed() for all active ItemLists.  Also refactored ItemList a bit.
ItemTracker Changes/Fixes

Made some changes to ItemTracker in preparation of switching the frontend code
to using it.

- Added ability to use conditions from the feed table in ItemTracker.
- Added ability to execute more complex WHERE clauses to ItemTracker.
- Fixed exception when we tried to load items after they've been changed.
- Renamed items() to get_items() to match the old ItemList code.
- Added ability to lookup the index of an item
- Added the will-change signal
- Added docstrings to ItemTrackerCondition and ItemTrackerOrderBy
Adding GTK tree module to use for the new frontend system.

This one is very dumb, it just implements a fixed-size list and relies on the
cell data functions do all the work.
Started using the new ItemList in the frontend code.

Lots of refactoring was required.  In particular ItemListController and Item
were changed to work with each other.

Implemented the sorts/filters from the old item list code.  Some of them still
have some work to be done.

Renamed the type of channel folders to "feed-folder".  I think this means that
users will lose their saved settings for those tabs (scroll position, which
list is active, etc).  We could fix this with a DB migration, but I don't
think it's so important.

Removed old TableView code for bulk changes.

Don't add a background widget between StandardView and its container.  I'm not
sure why exactly, but this prevents GTK from using the fixed height
table optimizations.

Made it so we initialize the data package during frontend startup.

Made it so we don't keep around the audio/video tabs forever.  The new code
can fetch the items for those displays fast enough that we don't need this
hack anymore.

Changed ItemList.get_group_info() to return the first item in the group like
the old function used to.