Update document and some tests weren't handling the multi-valued index logic.

The fixed implementation of update document isn't as efficient as could be.
We expect documents to frequently get updated without their indexes changing,
so that still seems like a worthwhile case to handle explicitly.
Updating a document now does a diff between the previous indexes and the new
indexes to make sure only changed indexes are updated.

This is significant as we expect many document updates to change none or
only some of the indexes. The diff isn't particularly efficient, but it
happens outside of any locks and should be happening over a relatively
small array. If it did prove a problem, switching the meta's indexes to a
set would be simple and effective.
Ranged queries can not be done against the sort index, provided the sort index
is a dynamic sort index.

The fact that we have 4 different index implementation, and 3 different query
paths is a pain. If everything was a "dynamic sort index" (aka, some type of
tree), things would get simpler and more powerful. Nevertheless, there's
some serious memory-win by creating a static index when you know you won't
be doing ranged base queries against it.

What would be nice is being able to know the # of elements within a range.
I believe this is doable with an indexable skiplist, but whether there's any
real value in this needs to be tested. (the benefit would be to direct
more calls to findBySort by the range is small, but since calls which go to
findByIndex are already small, I'm not sure what real benefit this would have).