selectTowards shan't call cursor.startSelection()

Should've been removed from MathCommand::selectTowards way back:
https://github.com/mathquill/mathquill/commit/44e5c97ece0c459fe6714d83e9b27b9015706709#commitcomment-5768270

Should never have been in TextPiece::selectTowards in the first place,
this is what I really meant to do to fix the anticursor's tree pointers.
Doing cursor.startSelection() worked because this line is only reached
in the case that the cursor and anticursor are at the same point in the
tree.
Move Cursor::{start,end}Selection before ::select #cleanup

Because Cursor::select relies on Cursor::startSelection, and it's gonna
rely on it more.
Persistent anticursor ancestor map inst. of Fragment.between

While selection is in progress, the tree can't change (typing calls
Cursor::endSelection via the `notify` system), so there's no reason for
Fragment.between to do its stupidly complicated and prematurely
optimized tree traversal every time, when it's much simpler to get the
whole ancestor chain of the anticursor once, then have the cursor just
check against that to find the LCA and the ends of the selection.

Since this is now inlined directly into Cursor:;select, the test cases
were moved out of tree.test.js into their own select.test.js.

Also, prep for MathCommand::unselectInto using the anticursor's reverse
ancestor chain instead of .selectedOutOf (which is only set if the
selection was initially made by keyboard rather than mouse), and for it
being possible for the directionality of the selection (whether the
cursor was to the left or right of the anticursor, and hence which end
of the selection it should be at) to be available to Cursor::select (see
next commit).
Fix #172: keyboard select after mouse select

- mouse selection doesn't call .selectOutOf(), and hence didn't set
  .selectedOutOf, which keyboard .unselectInto() relied on; now use
  anticursor's reverse ancestor chain instead

- cursor needs to be at the moving edge of the selection, which is
  always true with keyboard selection, but with mouse selection, the
  cursor could be nested arbitrarily deeply inside the selection; now,
  Cursor::select determines the direction of the selection and inserts
  the cursor at that end of it (and the mousemove handler no longer
  moves the cursor after calling cursor.select())

- finally, the mouseup handler no longer deletes the anticursor
Fix keyboard events during mouse selection

Cursor::select throws if there's no anticursor, i.e. if
Cursor::startSelection hasn't been called since the last call to
Cursor::endSelection, which is called by many keyboard events
(any .notify() call except 'select', in fact)

Now, if any keyboard events happen during mouse selection, we restart
selection starting from the new cursor position the keyboard event put
us in.
Fix Cursor::select() test case typos #ImAnIdiot

I'm dumb and this should have been done with the rest of
711aefaaf793cf91e72b63e974780e80b79c01ee, which added to
Cursor::select() reliance on a selection fragment actually
being created, and moving the cursor (which will call blur on
the cursor's previous parent).

https://github.com/mathquill/mathquill/pull/266#issuecomment-38870694
Move {MathBlock => Node}::selectChildren

So now MathCommand overrides selectChildren.

This cleans up TextBlock slightly, which is nice, and the
Cursor::select() test case that monkey-patches selectChildren on a plain
node looks more congruous, as the monkey-patched method tail-calls the
method it overrode, almost like a _super call
.selectChildren() now returns selection fragment

Simplifies the contract of .selectChildren() and de-duplicates the
assignment to cursor.selection. Plus, reduces manipulation of cursor
properties from outside cursor's own methods.
Make Selection() take fixed number of arguments

The shortcut is only ever used in one place, and resulted in a
hard-to-debug infinite loop that could've been immediately debugged
if a prayer had failed instead:

When writing the previous commit, at first I forgot to change the
signature of Node::selectChildren() from (cursor, leftEnd, rightEnd) to
(leftEnd, rightEnd), but changed everything else. So,
Node::selectChildren() was being called with 2 arguments, leftEnd
had what was actually the right end of the selection and rightEnd was
undefined, so Selection()'s constructor was in one-argument mode and the
cursor's selection was always a one-node fragment of what should be the
right end node. EditableField::select, then, which does

    while (ctrlr.cursor[L]) ctrlr.selectLeft();

infinite looped, since the selection never changes.
Merge pull request #266 from mathquill/fix.keyboard-select-after-mouse-select

Fix #172: keyboard select after mouse select