feat(math): Support TeX-like syntax for roots with degrees

[Omikhleia]

Closes #2225

Supporting \sqrt[degree]{radicand} requires support from the parser due to the unusual syntax with a math expression between square brackets.

This draft PR does work nicely for simple cases, e.g.

\sqrt[17]{7 + \sqrt[19]{A}}

It's however insanely slow for deeply nested constructs, e.g.

\sqrt{1 + \sqrt[3]{2 + \sqrt[5]{3 + \sqrt[7]{4 + \sqrt[11]{5 
   + \sqrt[13]{6 +  \sqrt[17]{7 + \sqrt[19]{A}}}}}}}}

(From Joe's MathML Browser Test, "nested roots" scenario)

This being said, the "MathML-like" approach (without any change needed to the current parser) suffers from the same problem. The simple cases works too in a timely manner.

\mroot{7 + \mroot{A}{19}}{17}

But the deeply nested cases is also equally real slow (to a point where this is not acceptable).

\msqrt{1 + \mroot{2 + \mroot{3 + \mroot{4 + \mroot{5
   + \mroot{6 + \mroot{7 + \mroot{A}{19}}{17}}{13}}{11}}{7}}{5}}{3}}

Just to be clear, a very (very) long time is then spent in convertTexlike() that just calls the LPEG/EPNF parser... (The time spent afterwards in the tree massaging for conversion to MathML is negligible).

So the slowdown isn’t caused by the proposed "sqrt" parsing rule itself, but by the heavy recursion in our grammar overall. LPeg’s backtracking makes this cost grow exponentially with nesting depth --- the real bottleneck is likely the general deep recursion in "mathlist" constructs...¹

Both KaTeX and MathJax are blazingly fast when it comes to render the long nested TeX example...²

So my suggestion would be to accept this PR (so that users would have the usual TeX-like construct support for regular cases, and it's not worse than the MathML-like workaround)...
... But perhaps should we open a dedicated for fully replacing our LPEG-based parser with something more efficient. Aye, this is a painful observation. (EDIT --> tracked as #2343)

Footnotes

1. For the record, the degree rule in \sqrt as proposed in the PR uses a - P("]") on a large element pattern: this will cause some inefficient backtracking too. A faster approach there would be to to parse a shallow "mathlist" specifically for the degree. Still, the performance bottleneck is reached with nested \mroots or even \msqrts... So while the degree root is not of the best efficiency, it's also negligible in this scenario... ↩

2. And Typst is real fast too with its own syntax sqrt(1 + root(3, 2 + root(5, 3 + root(7, 4 + root(11, 5 + root(13, 6 + root(17, 7 + root(19, A)))))))) -- Just sayin' ↩