This huge html chunk slowes down extract_av_tags to a crawl and crashes anki.
#3189

Looked into why this was happening, seems to be the recognize(manyX(pair(not(<parser>)), anychar))) pattern, which calls <parser> on every single character. This was fine in 2021, but after #1968 and #2141, cards with deeply nested clozes commonly result in extremely bloated* inputs that it can't handle fast enough

The speedup is mainly realised by making use of memchr to skip ahead to occurences of [, a prefix of tags. Also, when nested within recognize, manyX needlessly allocates a vec, populates it per character and then throws it away. This pr removes that from text_node and closing_parser as well

Benchmarking with rslib/bench.sh, using the deeply nested malformed cloze example**, before and after:

anki_tag_parse          time:   [85.267 µs 85.434 µs 85.645 µs]

anki_tag_parse          time:   [345.20 ns 346.54 ns 348.72 ns]
                        change: [-99.596% -99.594% -99.591%] (p = 0.00 < 0.05)
                        Performance has improved.

Where this appears to shine: was able to raise the nested cloze limit from 8 to 10 and open up the preview of the abovementioned malformed example without anki complaining of a blocked main thread (pre-pr: ~3.5s stall on my machine, a >94% speedup)

I can't see any breakage resulting from this. Only the internal representation was changed, i.e. consecutive text nodes are now possible, which shouldn't result in changes to the syntax this parser admits. Tested with decks that use sound and tts tags

*the mentioned malformed example gets blown up to 3mb when passed to the parser
**before (nested) cloze metadata gets added to it