Handle code blocks that use > 3 backticks in syntax highlighting

[DanTup]

Note: This is largely a copy of the same changes in dart-lang/dart-syntax-highlight#98. The grammar file lives over there but is copied into here to be used by the debugger syntax highlighting, and the grammar parser lives here but is copied over there to be used for tests. If you are reviewing one of these PRs, it might make sense to also review the other :-)

Code blocks can use more than three backticks in markdown so that triple-backticks can appear inside the content. They can also be closed with any number of backticks as long as it is more than the number that opened it.

I've committed this in two parts to make reviewing the diff easier. The first commit adds some additional tests and captures their golden output, the second commit has the fix and updated golden output. By reviewing them individually, it may be clearer what changed.

I also had to update the Dart implementation of the grammar parser to support using the \\1 reference in end to read the number of backticks from begin. This is consistent with the behaviour in VS Code (as can be seen in the screenshots below, which are rendered using VS Code's grammar parser - ours here is used only for tests here, but also for the highlighting in DevTools).

Before (the orange areas should all be a single code block):

After:

Related PRs:

• Handle code blocks that use > 3 backticks dart-lang/dart-syntax-highlight#98 - Updates the source grammar file, but also contains the updated grammar parser for its tests
• Update Textmate Grammar to support more than 3 backticks for code blocks Dart-Code/Dart-Code#6197 - Applies this change to Dart-Code

[gemini-code-assist]

Code Review

This pull request improves syntax highlighting for fenced code blocks in Dart doc comments that use more than three backticks by updating the Dart syntax definition and modifying the multiline matcher to resolve backreferences in the closing regex. A critical issue was identified in span_parser.dart where accessing beginMatch.group(groupIndex) without checking the group count could throw a RangeError, and a guard condition was suggested to prevent this.