PR Summary

1st commit: Switch svg glyph references back to hex; merge tex & non-tex names.

When embedding glyphs as paths in SVG files, each glyph has a name just
so that we can link to them when actually placing the glyphs.
Previously there were two different paths for non-usetex glyphs and
usetex glyphs.

• Ina2287b1 I accidentally changed the number component of non-usetex
  names from hex to decimal (usetex was always using decimal); switch it
  back to hex as that's typically how glyph tables are listed anyways.
  Also switch the usetex case to hex for consistency.
• Make non-usetex and usetex names use the same way to generate the
  name. The 2nd entry of ps_font_info typically matches postscript_name
  (but is only available for Type1 fonts, whereas postscript_name is
  defined for all fonts), but even if they donn't (see test_unicode_won),
  this doesn't matter as long as we are internally consistent...
  Also changed unicode_won test to actually parse the xml -- the regexp
  search seems quite slow locally, and anyways regex'ing xml is not
  necessarily a great idea :)

2nd commit: Record svg glyphs in 1/64 pixel units.

1/64-pixel is the "natural" unit for TrueType and FreeType ("F26Dot6").
Using it makes glyphs recorded in SVG files shorter, e.g.

M 88.796875 4.296875Q 88.796875 2.09375 87.140625 0.5Q 85.5 -1.09375 83.203125 -1.09375

becomes

M 1113 -72Q 709 -72 476 233Q 244 538 244 953

(the concatenated svg output of test_mathtext.py is ~10% shorter)
and easier to compare with FreeType values when troubleshooting font
embedding. An additionaltransform="scale(0.015625)" (i.e. 1/64) is
added at the end to scale the glyph, but given that a further scaling
and translation is done to actually render the glyph at the right size
and position in the svg, I doubt that this really affects svg renderer
performance (likely they can compose the two scalings first).

PR Checklist

• Has Pytest style unit tests
• Code isFlake 8 compliant
• New features are documented, with examples if plot related
• Documentation is sphinx and numpydoc compliant
• Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
• Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way