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.

Removed old resort_on_update() code.  I'm not sure how it would work with the
new system, and I'm also not sure if it's needed anymore.

Changed ItemList.get_group_info() to return the first item in the group like
the old function used to.
Fixes to make things work on windows.

Fixed setup.py
Don't use extra arguments for namedtuple.  They're not supported on python
2.6.

Don't create a connection when we first create the ConnectionPool.  This
leaves the file open on windows, so we can't delete it.
Implemented things on OSX.

Changed the ItemListModel api so that item_list[row] returns the tuple
(item_info, attrs, group_info) instead of just (item_info,).  This is how
InfoList used to work, and I think it makes sense.
Removing tempdb code.

It was not a great idea to begin with.  Using no journaling mode is
interesting, but we actually prefer WAL mode over it.  Otherwise the
backend can't write to the database until the frontend is done reading it.
This is a performance issue, but it can also cause deadlocks.

We actually still have that same issue on databases where we fail to change to
WAL mode.  Added a FIXME note about this.

Removed the code to delay saving the RemoteDownloader objects to disk.  We
need to update the DB for each status update now.  Removed rate_limit code it
doesn't make sense with the new system.
Release our connection when we finish with ItemLists

This is useful if the user switches to a tab with lots of items then switches
away before we've fetched all the row data.  In that case, we don't want to
continue fetching row data.
Bunch of fixes for the new code.

Added a bunch of sorts and stubs for sorts that are harder to implement.

Implemented filters

Re-implemented get_group_top() and iter_for_row()

Fixed various other issues with the new ItemInfo class.
Adding support for full-text searches.

Made backend-support and a unittest, then hooked the frontend code.

Added debugging printout when we run queries for the new item list code.
Re-implemented playback.

Rewrote PlaybackPlaylist to use the new ItemList code and hopefully be a bit
simpler than before.

Fixed some issues with ItemInfo attributes that were used in the playback
code.