[iOS]: anyTextHaveBeenModified performance

Describe the bug
At the moment, when working with a medium-sized text and typing quickly, the caret and text updates can feel noticeably laggy. This appears to be caused by anyTextHaveBeenModified being executed on every text change within the text view. Since this method iterates over the entire input range and processes blockquote and inline code colors, heading styles, and zero-width spaces, it is relatively expensive.

In practice, this results in a performance cost of approximately 25 ms per single character change for an HTML input of around 3k characters, which is not particularly large.

Proposed solution

1. It may be worth reconsidering whether color handling is necessary inside textViewDidChange. Similar to the approach used in the foreground color styles PRs, this logic could potentially be handled elsewhere, with base colors restored in the same way if needed.
2. Improper headings could likely be resolved in a single pass, rather than running separate logic for each heading style.
3. At this point, it is unclear how best to handle zero-width spaces. However, with the new parser and serializer implementation, it may be unlikely for them to appear in the text view at all.

Expected behavior

Typing shouldn't be laggy

Screenshots
If applicable, add screenshots to help explain your problem.

Device (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

Start by locating anyTextHaveBeenModified and its call from textViewDidChange, then profile typing in a roughly 3k-character HTML input. Review the color, heading, and zero-width-space processing described in the issue; done means character edits no longer cause noticeable caret or text-update lag.