I'm seeing weird behavior from SortedMap.slice and .sliceIndices. I
think the docs, tests, and/or code is wrong.

For lists, .slice is documented to take [lower, upper) bounds. But for
sorted maps, .slice apparently takes [lower, upper]: both inclusive.
That's kind of weird in itself--possibly it's shaped this way because
it's not always clear how to construct a successor to the max element. The
code certainly looks like it's intended to be both inclusive. Except it
doesn't actually *do* that. Slicing to 0, 0 returns the *entire* map
somehow. Slicing to 1, 1 yields the empty map. Slicing to 3, 8 yields
just 3, and skips 4.

There were no tests for .slice--only .sliceIndices, so I added some.
Commit 65e43ad says that it fixed the
tests for sliceIndices to reflect their inclusive, inclusive behavior.
but the commit actually does the opposite: it makes the test for
inclusive, exclusive.

We should align the tests and code to whatever the behavior is supposed
to be. We should also document the inclusive/exclusive behavior for
sliceIndices etc. It's not actually written down, and that's terribly
confusing.

This method was broken when iterators had different numbers of elements.