Replace regex-based HTML entity parsing with handwritten code

[jakebailey]

I'm on a quest to eliminate regexes from the shipped code as much as possible.

This one is not trivial, but it's not too bad either when split up.

[Copilot]

Pull request overview

This PR replaces regex-based HTML entity parsing with handwritten code to eliminate the regexp2 dependency from the JSX transformer. The change maintains the same functionality while using a manual string parsing approach.

Changes:

• Removed dependency on github.com/dlclark/regexp2 package
• Replaced htmlEntityMatcher regex and htmlEntityReplacer function with handwritten parsing logic
• Split implementation into decodeEntities (main parsing loop) and decodeEntity (single entity decoder)

[Copilot]

The slice operation text[1:semi] is incorrect. At this point, text has already been sliced to start at the & character (line 871: text = text[i:]), and semi is the index of ; within this already-sliced text. Therefore, text[1:semi] correctly extracts the entity name between & and ;. However, on line 883, when the entity is not recognized, the code writes text[:semi+1] which includes the & at position 0 through the ; at position semi. This is correct. But consider the edge case where text = \"&;\" (empty entity). In this case, semi = 1, so entity = text[1:1] which is an empty string, and decodeEntity(\"\") returns (0, false). Then line 883 writes text[:2] which is \"&;\". This preserves the invalid entity correctly. The logic appears sound upon closer inspection.

[jakebailey]

Hilarious circle

[weswigham]

You know, reading this is making me realize we probably need to be doing this in the parser stage so the .Text() of JsxText as read by the checker is post-entity-decoding - I think the only reason it ends up not mattering is because the literal type of a JsxText element isn't currently accessible - but if we ever did start typing jsx children better, it'd matter.

[jakebailey]

Yeah, that would match other string values and so on...