first half-attempt at a flexible attribute schema

This uses two tables, item_attributes and album_attributes, as key/value
tables for the respective entities. Plugins register fields, at which point
they are magically materialized as properties on Items (Albums are not done).
This currently supports adding and modifying these fields but not retrieving
them (which will need some sort of join).
An attempt at flexible attributes with plugin namespaces.
Mostly untested.
Started hacking `CollectionQuery` to search flexible attribute fields.
Fixed up a couple of query classes for flex attr support.
ironing out some kinks
Code for reading attributes from concatenated flex columns into dicts moved to an outside methods to make it usable for both BaseAlbum and Item objects.
Merge pull request #208 from steinitzu/flexattr

partial flexattrs
experiments with "un-registered" flexattrs
get and set flexattrs with hyphen keys

Here's another little experiment: to make flexattrs a little easier to use for
end users, you can now get and set them by using 'namespace-key' as the
argument to __getattr__ or __setattr__.

For example, try:
$ beet mod foo-bar=baz
$ beet ls -f '${foo-bar}'
baz
baz
baz
...
reduce redundancy in item queries

Now the SELECT query for items only appears in Library.items(). All other
functions that retrieve items go through this method. This should make it
easier to change the way flexattrs are picked up.
merge with master

We should work off the latest changes because of the recent changes to the
Query class hierarchy.
merge with master
drop flexattr namespaces

Namespaces were a worthy idea, but they added a lot of complexity to both the
library code itself and every client of the flexattrs interfaces. Getting rid
of them, and having one flat namespace of both traditional fields and
flexattrs, has one huge benefit: we can "promote" flexattrs to real attributes
(and vice versa) without code changes in every client.

This frees us to have a somewhat less efficient implementation of flexattrs
because we have a smooth upgrade path for making attributes more efficient via
promotion.
introducing "slow queries"

In preparation for enabling queries over flexattrs, this is a new path that
lets queries avoid generating SQLite expressions altogether. Any query that
can be completely evaluated in SQLite will be, but when it can't, we now fall
back to running the entire query in Python by selecting everything from the
database and running the `match` predicate.

To begin with, this mechanism replaces RegisteredFieldQueries, which
previously used Python callbacks for evaluation. Now they just indicate that
they're slow queries and the query system falls back automatically.

This has the great upside that it lets use implement arbitrarily complex
queries without shoehorning everything into SQLite when that (a) is way too
complicated and (b) doesn't buy us much performance anyway. The obvious
drawback is that any code dealing with queries now has to handle two cases
(slow and fast).

In the future, we could optimize this further by combing fast and slow query
styles. For example, if you want to match with a substring *and* a regular
expression, we can do a first pass in SQLite and apply the regex predicate on
the results. Avoided for now because premature optimization, etc., etc.

Next step: implement flexattr matches as slow queries.
flexible attributes as slow queries

Queries over flexible attributes now Just Work!
new FlexModel base class

I intend to use this for both Item and Album to avoid code duplication and
simplify code that uses both entities.
kill BaseAlbum

I added this back when I thought I would implement a different subclass that
represented iPods. That means I wrote this code when I had a lime iPod mini. I
am old.
flexattrs work for Albums

A second base class, LibModel, maintains a reference to the Library and should
take care of database-related tasks like load and store. This is the beginning
of the end of the terrible incongruity between Item and Album objects (only
the latter had a library reference). More refactoring to come.

One large side effect: Album objects no longer automatically store
modifications. You have to call album.store(). Several places in the code
assume otherwise; they need cleaning up.

ResultIterator is now polymorphic (it takes a type parameter, which must be a
subclass of LibModel).
remove count() calls

I removed this method in an earlier commit.
revamp ResultIterator (now Results)

This new design lets us provide better common functionality. The `get()`
method is a particularly good example: we can now avoid the try/except dance
that was previously necessary to get the only result for a single-result
query. This also lets us continue using `len()` on the result of
`album.items()`, which previously returned a materialized list.