Use glyph indices for font tracking in vector formats

[QuLogic]

PR summary

With libraqm, string layout produces glyph indices, not character codes, and font features may even produce different glyphs for the same character code (e.g., by picking a different Stylistic Set). Thus we cannot rely on character codes as unique items within a font, and must move toward glyph indices everywhere.

The only thing I don't quite like is that PDF uses character codes for its lookup, and I have to map glyph indices back through an inverse charmap. I think I may have to send everything through CharacterTracker and produce my own limited charmap, but still need to test out what's required. Better stuff for this is done in #30512.

This is based on #30143.

PR checklist

• [n/a] "closes #0000" is in the body of the PR description to link the related issue
• new and changed code is tested
• [n/a] Plotting related features are demonstrated in an example
• [n/a] New Features and API Changes are noted with a directive and release note
• [n/a] Documentation complies with general and docstring guidelines

[QuLogic]

I've decided to restore the character code in the return values from mathtext, because I've found some use for it in PDF output.

[anntzer]

Looks like mypy is unhappy for unrelated reasons (beyond the disjoint bases issues) so that can probably be fixed as a separate PR.

[QuLogic]

I've rebased #30512 as well now. Of course, I wrote the change much after this one, but now it does seem like they go together quite well, so let me know if you want me to move the "pdf/ps: Track full character map in CharacterTracker" commit here to review together.

[anntzer]

I don't really mind either way, the advantage of splitting things in smaller chunks is that once a PR is done we can just forget about it and move on to the next one (whereas if you add another patch here there's no easy way to state "the first commit is ready to go but the second still needs review"). More specifically, it seems to me that the UI of github is not really optimal in that reviews (and the approval process) are "PR-oriented" whereas for these large, multi-step PRs, it would be useful to have "commit-oriented" reviews. Given the current limitations I would suggest splitting the charmap tracking commit into its own PR (on top of this one) as well as I suspect (no guarantees) that it can also be approved quickly.

[anntzer]

Edit: I reviewed that commit and would approve it except for the two doc-related comments I've left.

[QuLogic]

Given the current limitations I would suggest splitting the charmap tracking commit into its own PR (on top of this one) as well as I suspect (no guarantees) that it can also be approved quickly.

OK, I split that into #30566, and fixed the comments as well.