This PR fixes several problems with font extensions that define new font variants, and allows non-standard variants to round-trip through SRE without causing verification errors (now that we are checking mathvariant values in MmlNode).

Currently, the ignore-variant property is used to determine whether a node's non-standard mathvariant should produce an error message when used in MathML input, and non-standard variants can be specified using the data-mjx-variant attribute. The presence of that attribute sets the ignore-variant properly when a MathML element is created by the MathML input jax, and the serialization of the node via MmlVisitor and its subclasses would add the data-mjx-variant attribute when ignore-variant is set.

In this PR, the MmlVisitor is modified to remove the mathvariant when ignore-variant is set (and data-mjx-variant is added as before), since the variant is non-standard and should not be included in actual serialized MathML.

In the past, when a non-standard variant is needed in TeX output, the ignore-variant property would need to be added by hand. If the parser's stack.env.font is a non-standard variant, this was not being done, and so if a non-standard variant is needed in a font extension (as with the IEEE Euler fonts), this would lead to an error during parsing of the MathML generated during SRE enrichment. To fix this, the TexParser is modified to set the ignore-variant when any token node is created with a non-standard mathvariant.

The mergeOptions() function in the common FontData.ts, which is used to merge font-extension information into an existing font, was not working properly, so this PR fixes how the merge is handled: it now modifies a named property of the font instance rather than using arrays, which never worked, and I don't know what I was thinking, as that makes no sense. The uses of mergeOptions are updated accordingly.

Finally, the SVG version of FontData.ts is modified to add a cacheIds property to the data for font extensions in SVG fonts, as these are needed to name the font caches for any new variants that the extension adds.

All this will allow a custom IEEE Euler font extension that stores the needed characters in separate variants, like in their v2 extension.