Key-based sort.

This rewrites the sorter to generate "keys" for each doc and find the
lexicographically minimum "key", rather than to look at each sort key
field separately.

This commit doesn't actually change the semantics (and the failing test
still fails) because the key generator actually still computes the full
cartesian product of all keys, rather than only using fields that are
next to each other in arrays.
Make sorter closer to Mongo sort key semantics

Specifically, this ensures that with sort specifier {'a.x': 1, 'a.y': 1},
{a: [{x: 0, y: 4}]} sorts before {a: [{x: 0, y: 5}, {x: 1, y: 3}]} by
ensuring that the latter only has sort keys [0,5] and [1,3], and not
[0,3].

It does this by ensuring that the different fields used to generate a
sort key are only matched up if they use the same "path" (series of
array indices used during lookup).  This is a little stronger than what
MongoDB does: MongoDB lets you do {'a.x': 1, 'a.y.z': 1} where 'a' and
'a.y' are both arrays, and our new rule requires all fields to have
either the exact same set of arrays or to use no arrays at all.

(MongoDB does still have some constraints; eg, with sort key {a: 1,
b:1}, a and b cannot both be arrays.  Basically, there may be at most
one "outermost" array across all the fields; and so on recursively, sort
of.

The previously failing test passes now.