Paint selection gaps to mark line endings

DRQS 38038836
If a line does not have a right gap, but the selection extends past the end of
the line, then we should paint a small gap to indicate that the line ending has
been selected.

This is implemented in a new function called 'lineEndingSelectionGap', which is
similar to 'logicalRightSelectionGap', except that it limits the width to five
pixels.

Also, the lastLogicalRight for a block now extends to the last selected line's
logical right, including the line ending gap.
Fix lastLogicalLeft when selectionStartsOnLastLine

Previously, if the last selected line had no selection rect, our
lastLogicalLeft would be flushed against the left of the root block, because
the returned selectionRectForRepaint would be empty.

Now, when selection starts on the last line, we initialize lastLogicalLeft to
the *right* of the line (this is where the line ending gap begins).  Then, if
the line has a selection rect, we move the lastLogicalLeft to the selection
rect's left.
Allow line ending highlight to go into padding

This is necessary for right-aligned text.  If there is no padding, then the
line ending will not be highlighted.  However, if there is padding from the
line to the root block, then we can make use of that space for the highlight.
While it is technically bad to paint into the padding area, this may be an
exceptional case.

Also, adjust the width of the line ending gap to be based on the line height,
instead of being hardcoded to five pixels.  Now, the width will be one quarter
the line height.
Make line ending highlight work for RTL blocks

The previous logic for line ending highlights only worked for LTR blocks.  This
change makes it work for RTL blocks as well.

The getLineEndingGapLogicalRight method has been replaced with the
getLineEndingGapLogicalLeftAndRight method, which returns *both* the left and
right positions of the line ending gap.

Also, the calculation of lastLogicalLeft and lastLogicalRight for blocks with
inline children has been fixed to handle RTL blocks as well.
Fix selection gaps on before & after side of cells

In the previous code, the before-side of table cells would be filled across the
entire width of the cell, and only if the selection started before the table
cell.  Also, the after-side of table cells would only be filled if the
selection ended after the table cell.

Now, the after-side of the table cells would be filled if anything in selected
at the end of the cell.  This is done by making inlineSelectionGaps and
blockSelectionGaps set an "isAfterSideSelected" flag if the last item in the
block had anything selected.

Also, the before-side of table-cells will now be filled if the firstRootBox is
selected.  The issue where it filled the entire width has been fixed by setting
lastLogicalLeft and lastLogicalRight to the left & right selection coords on
the first line.  This is done by refactoring the old logic of determining
lastLogicalLeft and lastLogicalRight of the last selected line.  This logic is
now in a new method called "getLineSelectionLogicalLeftAndRight".
Revert recent changes causing regression

Reverted commits 63d5cfc to b477fc8

This reverts commit b477fc85f7388c59c78bba5782106425924bb0f2.
Restore recent changes causing regression

This reverts commit ae7ce8e8cc7ef0ea1d749ba382d8e8900578c4bc.

The regression issue will be fixed in a subsequent commit.
Handle recursive blocks when highlighting cells

DRQS 39217949
The previous logic we added for highlighting the before and after side of cells
did not work correctly for recursive blocks inside cells.

In this change, we add two flags to the selectionGaps() context:

* shouldHighlightBeforeSide
  This is set to true for table cells, and is set to false whenever we
  encounter an unselected child and after the painting the first highlight on
  the before-side.

* isAfterSideSelected:
  This is the same as the flag that was added to inlineSelectionGaps and
  blockSelectionGaps, but now we have this also for selectionGaps, so we can
  handle recursive blocks.