Pushes efficient order_by once step closer  to reql.
In theory efficient order_by works.
order_by now passes smoke tests.

Seems to be working.
Fix a bug that lead to a crash.
Adds a buffer group iterator.
Adds begin and end methods to buffer_group,
Push sindex function through to traversal callback.
Makes passing sindex functions optional.
Return sindex_key if its truncated & we're sorting

It's needed to reconstruct the ordering.
Get rget_item_ts in batched_rget_stream_t.

This will allow us to accurately sort in the case of truncated sindex
keys.
order_by won't choke on long sindex_keys.

In theory now even if you have sindex keys with a very long common
prefix this will still sort them correctly and as efficiently as
possible using the index. Now begins debugging.
Fix bugs in sindex ordering.

My reasoning for when a key was too long and needed to be truncated was
wrong.
Remove buffer_group_const_iterator_t.

It wasn't being used just an artifact of another approach to fixing
order_by.
Remove and unneeded include.
extended_json_list_t -> extended_json_deque_t

That name makes more sense.
Make head and pop be private.

They weren't used publicly anyways.
Remove an unneeded debugf.
Error rather than sorting too man values in memory.

We already do this with the old form of order_by but we can get in to
this same situation with indexed order_by if there's a secondary index
with over 1000000 sindex values with a very long common prefix. This is
an unlikely situation but still we handle it.
Don't mix items with different truncated keys.

Before if we got back consecutive items with truncated but different
secondary keys we would put them all in the sorting buffer and sort them
inefficiently all together. This had the problem of being inefficient
and also could lead to hitting the in memory sorting limit when it
shouldn't.
json_stream_t now returns sorting hints.

This is needed so that we can combine index based sorting with in memory
sorting.