Use split_parser branch for markdown grammar

[MDeiml]

See #3072.

Only a draft because markdown_inline grammar is not injected properly, but to me it seems like this is a problem with helix and not the language config? After a few experiments I think the grammar is injected, but highlighting is still not done according to the injected language. I'm not very sure though.

Another weird behavior is with fenced code blocks. They seem to work to some degree, but if you enter something like

```rust
let foo = "bar";
```

then let is highlighted correctly while "bar" is not highlighted at all.

[MDeiml]

Changing this to ready since I found a solution to the problems in #3129.

[the-mikedavis]

I tried this branch locally but I don't see any qualitative improvements to performance (we'll need some measurements like from #940 to be definitive). Specifically I see the some slowness with incremental updates while editing (for example typing quickly in insert mode) on a reasonably large and complicated markdown document like the changelog. Is this branch of the grammar(s) more correct than master? This doesn't feel like a regression so I'm certainly not against merging it but I'm curious what the improvement is of splitting the parsers?

[MDeiml]

I'm no longer maintaining the master branch, I just kept it because some projects seem to depend on it.

It was not really possible to implement a correct enough markdown parser in a single grammar. The specs also recommend to parse markdown in 2 passes. Now after splitting it into 2 grammars they work closer to that recommendation.

They're more correct now and with some optimizations to incremental parsing I think they'll also be faster. (But that'll be topic of future PRs).

[MDeiml]

Specifically I think that tree-sitter reparses all injected ranges if they contain "conflicts" no matter if they changed or not. That means that parsing is linear with the number of injected ranges. I think we could just not reparse ranges if they did not change at all (parsing should be deterministic with regards to the input anyways).

[the-mikedavis]

I'm not very familiar with the changes but I think archseer might've covered that when implementing combined injections: 6728e44...7c9ebd0

We don't use the stock tree-sitter-cli highlighting code since it isn't incremental

[MDeiml]

Just looking at the code that doesn't seem to be the case, but I should do some more investigation.

[MDeiml]

It's related to this TODO:

helix/helix-core/src/syntax.rs

Line 724 in 681c0a9

// TODO: we should be able to avoid editing & parsing layers with ranges earlier in the document before the edit

Just going one step further and also avoid parsing layers that are after the edits

[the-mikedavis]

This works well for me locally but let's await further review/merging in #3129

[archseer]

Can you resolve the conflict? Looks good to merge otherwise 👍🏻

[the-mikedavis]

Works great! Thanks for working on this plus going the extra mile to add the new predicate :)