Since we compose the line wrapper and the line folder together, the
line map is not always translating between screen and buffer coordinate
spaces. It's translating one step in the chain, with output closer to
the screen and input closer to the buffer.
Added explicit options for controlling line wrapping, and skipping of
atomic tokens to the LineWrap.clipScreenPosition. These are used when
moving right to wrap to the next line.
Before, we were manually clipping the position of the cursor in
vertical movement methods. Now we can just increment / decrement the
row and the position will be clipped when it is assigned.
Also, changed the definition of clip screen position to always 0 out
the column when the row is negative.
This relies on a new `eagerWrap` option to clipScreenPosition which
will wrap positions inside of atomic line fragments (which is what fold
placeholders are) to the end of the fragment rather than the beginning.
It also wraps positions beyond the end of a hard line to the next line,
which means Cursor.moveRight just has to increment the column, then
call clipPosition with eager wrap set to true to get all the correct
behavior.
The key was in LineMap.linesForScreenRows. For each screen line, it
concatenates all line fragments (if there are indeed more than 1) that
traverse that line to return a single line fragment representing the
line. The key was to update the buffer delta for that fragment to
always be 1,0. Because the wrapper is treating the folder as if it's
the buffer, the lines it stores in its map need to traverse only a
single "buffer" line (that's a single line after folds are taken into
account). We may need better language than "screen" and "buffer"
because the wrapper treats the folder as the "buffer" but that's
confusing because it isn't.
The layered relationship between the line wrapper and the folder is
still not quite ironed out yet. The editor behaves pretty erratically
when text is folded.
