Moved the main index to an interface, and the implementation is now a
SimpleIndex. The move is to eventually allow arbitary ranged queries against
most than just the sort value. In other words, it'll be possible to use the
skiplist for a normal index.

Eventually I'd like to move towards 2 types of indexes. SkipList and
StaticScoreSort. This should simplify the code a lot.
This branch is focused on two things: simplifying the indexes and supporting
richer queries. To this end, only the skiplist index remains, and there's
no longer a distinction between sorting indexes and filtering indexes.

As a consequence, the following things have been removed:

- Query cache
- Efficient filtering
- Append/Prepend
- Bulk index load
- Aggregation

Efficient filtering is going to come back in the next commit. Query cache
should come back shortly thereafter.

The other three are doable, but I'll wait until they become necessary.

Documentation is also out of sync, and a lot of tests are broken.

I still think there's value in having a lightweight specialized index which
represents a pre-filtered state. But, for now anyways, we'll skip that.
A more efficient condition engine.

This definitely takes a ton less memory. It should also perform better,
particularly when the condition filters out a large number of values. It's a
shame checking for existance has such a deep callstack though.

Going to have to spend time performance testing it, but want to wait until
the query cache makes it back in.
tests around conditions
Fixed tests from yesterday's redo.
Sort condition is now apply as part of the sorting, which makes it much more
efficient.
- Proper index locking on query.
- Sort-only queries properly return the total, even when the sort is filtered
Brought back the post-filter query path. The three paths largely optimize
around iterating over the smallest index. However, when we apply filters first
we need sort after the fact, so this approach only makes sense when
  a) we're dealing with a small number of values (configurable, but some
     testing with the previous, almost identical implementation, suggest that
     1000-5000 is best)
  b) one of the filters is considerably smaller than the sort length

The query that I happened to be looking at went from ~40ms to 80µs.
Documents now have a type associated with this. This is used when reloading
the document. It forces a convention on consumers that they define a Type which
they'll be able to use when reserializing objects.
Query is now an interface. When querying against an invalid sort, an
EmptyQuery is returned, which no-ops every operations and returns an
EmptyResult when Executed