This commit makes autoscroll a 3-valued property on the cursor. If it
is set to true or false, that setting will stick until the cursor's
next visual update. That means we can explicitly move the cursor with
autoscroll set to false, but also still autoscroll by default when the
cursor's anchor moves on its own.
Any events emitted from DOM nodes should be prefixed with an identifier
for the node that emits them. This eliminates the possibility of ambiguity
when the events bubble up the DOM away from their emitter.
Rather than managing the visibility directly, a class makes it easy. The cursors will always be toggling this class on and off in the background, but only on the focused editor will it actually have an effect.
Also, when stopping blinking, set the cursor's visibility to whatever it is on the underlying model. This fixes issues where the cursor would blink when there was a selection.
This is actually more efficient than the CSS animation we were doing previously, because it doesn't force the cursor to be sampled at 60 FPS for something that changes around twice a second.
Then in the editor, we update and autoscroll only the views that need it. Autoscrolling is suppressed when resetting the display so that we honor the scroll positions of the active EditSession.
We no longer call `updateDisplay` immediately when the cursor is attached. Instead, we always attach and remove cursor views from `Editor#updateDisplay`, so we will decide whether to autoscroll at that level.
The goal is that no model operation will ever modify the DOM directly. We will always request a display update, which will happen on the next animation frame.
If the input element is a child of the scroll view, then focusing it can end up changing the scroll position of the view behind our backs. We *only* want to scroll the view via our interface on editor, because a bunch of of special code needs to run when we scroll. We can't just have the browser scrolling that view around willy-nilly.
SelectionViews now update their appearance immediately when constructed. We can't assume they're empty. CursorView doesn't do a blanket `off()` call to its model when it's removed anymore, which was screwing up selection updates when switching back. Only attach selections / cursors when the editor is attached, and extract everything we do into a `renderWhenAttached` method.
The old cursor view still does most of the work, but to add a new cursor view we now must add a cursor model to the edit session at the correct position. The editor watches the 'add-cursor' event on edit session and add a corresponding CursorView to the CompositeCursor whenever a model is added. Next step: have the cursor view observe the cursor model and shadow its changes in position.
