TextLeafPoint::FindBoundary currently only supports word and line start boundaries. ATK and Mac (and maybe Android) need word/line end as well.

For line end, we can probably just get line start and walk back a character to see if it's a line feed, and if so, return that. Word end will be more complicated.

These bugs cause problems for the upcoming implementation of BOUNDARY_LINE_END.

1. Don't always return no character at the caret. Only do that if the caret is at the end of the line. This was always the intent; this was just a silly mistake.
2. When moving to the next character in an Accessible, don't move past the last character. This was a simple off-by-one error.

BOUNDARY_LINE_END is implemented using BOUNDARY_LINE_START and adjusting for line feed characters, which are line end boundaries where present.

BOUNDARY_WORD_END is implemented using BOUNDARY_WORD_START and adjusting for spaces, which are word end boundaries.
This is arguably less efficient than it could be, since we will walk over space and then reverse course to compensate.
However, the alternative would mean keeping two slightly different versions of the word boundary check code in sync, plus compensating for the fact that a word often ends before a line start while still supporting words split by line wrapping.
I felt the lower complexity here outweighed the potential slight loss in efficiency.
We can always revisit this if this turns out to be a real problem.

Backed out 4 changesets (bug 1730085) for causing bp-hybrid build bustages.

Backout link: https://hg.mozilla.org/integration/autoland/rev/9f6becb18c01eaba34e64019911513e4de2bff93

Push with failures

Failure log

https://hg.mozilla.org/mozilla-central/rev/e0c116bd432b
https://hg.mozilla.org/mozilla-central/rev/6ae088ec6a5b
https://hg.mozilla.org/mozilla-central/rev/652f83237c7c
https://hg.mozilla.org/mozilla-central/rev/bf1bde768533