Better change tracking for Semantic highlighting for CSL

[lkishalmi]

Instead of tracking changes in a series of Edit records between parsing there could be Document Position used, which automatically track the offset changes in the edited document.

This version further simplifies the highlighter.

Also resolves a minor issue, that would not extend the previous highlight when the new text is just appended after a whole token.

Before:
Screencast From 2024-12-29 15-53-25.webm

After:
Screencast From 2024-12-29 15-50-57.webm

This may have better performance as well. There was some minor flickering on highlights when the edit list grew "large" (basically that needed a lot of monkey style keyboard clamping, to be noticeable)

I have a minor aversion to put Position which is a mutable thing info the SequenceElementrecord, though it is used to grouping data together, also changes in the document, shall not change the order of the instances when put in a collection, so I could live with that. Please tell me if you have something better in mind.

[mbien]

hmm. I like the simplifications. Although Comparable doesn't mention anything regarding mutability, i believe some sort methods will throw an exception when they notice that something changed during sort (somewhat analog to ConcurrentModificationException). But if it is accessed under the right locks - everything should be fine.

[lkishalmi]

At the end removed Comparable interface and added a static Comparator, in order to express that SequenceElements are not really compared, and make the usage of the required comparison more explicit.

[matthiasblaesing]

Before this is progressed further a regression needs to be fixed first. See #8102

[lkishalmi]

Rebased the code from master with @matthiasblaesing fix, added one more unit test to check the skipping of empty highlights.

[mbien]

looks good to me

[matthiasblaesing]

I saw nothing obviously wrong here.