Scan back to the containing syntax ancestor to compute highlights

[the-mikedavis]

This change starts the syntax highlight iterator before the
first visible byte of the source and then filters out highlights
which are not in the visible range.

The highlights iterator has some context that builds as it handles
tree-sitter QueryCaptures: locals/scopes tracking and the rainbow
matches nesting level. By starting at the start of the largest
containing node (if one exists), we can cover most cases where
locals tracking is noticeable and all cases for rainbow brackets
matching.

One edge-case remains for #1151: if the root node is
itself a local.scope, this change will not start far enough
back in the document to catch locals definitions which are out
of view.

---

For example, here's a fixed case for the locals tracking:

Before	After

(source)

cursor, captures, and layers are recognized as variable (italic white) rather than variable.other.member (blue) even though their local.definition is not within view. Some for source, range and cancellation_flag recognized as variable.parameter (underlined white) from the function's definition which is a few pages out of view.

And this fixes the rainbow view problem: https://asciinema.org/a/507564

[archseer]

There can be a lot of highlight nodes though. I'm thinking we should maybe scan certain queries over the whole document/wider area/parent node, but limit highlights to just the visible range. That would require two cursors though, then merging the two iterators at scan time.

[the-mikedavis]

Yeah good point, I don't really like the wasted effort either

I'll give it a go using a separate iterator and merging the two 👍