Drop unused variable in ViDocument.
Add viewWithTextView: to ViTabController.

This method returns the ViDocumentView instance in the
tab view corresponding to the given ViTextView, or nil if
there is no such instance.
Basic caret-based view left/right/up/down selection.

Now, when we select a view left/right/up/down from another
view, we check the caret in the view that we are moving with
respect to and do some coordinate math to figure out the
view that is left/right/up/down *of the caret*, rather than
simply selecting the top element in the split that is in that
direction.

A couple of issues currently:
 - If the caret is scrolled away, behavior is a little strange,
   because math is still done with respect to the caret
   position, even though it’s hidden.
 - There are some hardcoded numbers in there to jump over
   things like the gutter views and the split view hit areas.
 - If the caret is just right, the math to determine the text
   view in the appropriate direction will find a split view
   splitter instead and will fall back to the old behavior.
Use NSTextView's firstRectForCharacterRange to compute caret rect.
Compute and constrain reference point with respect to scroll view.

We now compute the reference point as a point in the scroll
view containing the text view. Additionally, we constrain it to
the scroll view’s bounds with some padding, so that if the caret
is off the visible scroll area, we keep the value we’re working
with within the scroll rectangle. That means we’ll never be able
to switch windows outside of the visible area of the current
view.
Search for text view until we run out of window in selectViewAtPosition:relativeTo:.

We start with an offset of 40 in the direction dictated by the
provided position, and then increase in multiples of 40 until
we are no longer over a view at all or we have found a
ViTextView.
While searching for a view to move up/down/left/right to, adjust for splitters.

Before, if going in the indicated direction from the caret
resulted in coordinates that were on a split view splitter, we
would simply fall back on the old behavior of going to the first
entry in the split in the given direction. We now adjust the
coordinates either rightwards or downwards (depending on
whether we’re looking for the next text view vertically or
horizontally) so as to move off of the splitter.
When searching for a view to move up/down/left/right to, recognize ruler views.

Before, hitting a ruler view would mean continuing to adjust in
the given direction, which when moving up or down would
mean continuing to look up or down for a valid text view. In
those cases, we wouldn’t end up finding one, or we’d end up
passing through the view immediately on top/bottom of the
current one to one further up whose ruler wasn’t in the path of
the caret point.

Now, when we see a ruler view or one of its children, we look
up the associated text view and select that.