Highlighting a carriage return is only attempted when it is not the last
character in a `Source` chunk. This skips highlighting for CR in two
cases: CR as the last character in a file and CR just before a highlight
event.

For the first, although EOF can be considered a line ending, in a sense,
CR+EOF shouldn't count as a CRLF line ending, so such a CR should be
highlighted.

For the second, it is more complicated. Since text is highlighted as a
stream of events (`HighlightStart`, `HighlightEnd`, and `Source`), we
cannot know while in a `Source` event whether we are the last chunk
without peeking forward through `HighlightStart` and -`End` events to
the next `Source`. The API takes an `Iterator`, so this isn't possible.
Luckily, it probably doesn't matter in practice, because grammars are
highly unlikely to want to split CR and LF with highlighting, so the
next `Source` won't start with LF anyways.

The updated test tests both of these cases. Commit 422e74f (chore:
update javascript-relevant tests, 2024-02-02) added the FIXME after
updating the JavaScript grammar, which caused `b` to become parsed as a
variable, triggering the second case.

If a CRLF is split between two `HighlightEvent`s, the previous commit
would highlight the CR, although it shouldn't. Fix that by tracking the
offset in the rendered HTML of the last CR and insert there once known.