Feature/tag texts

[dpvc]

This PR changes the handling of tags to make three separate mtext nodes: one for the left delimiter, one for the tag number, and one for the right delimiter.

The formatTag() and formatRef() functions now take either a string or a triple of strings to use for the tag format. If it is just a string, then parentheses, brackets, and braces are removed from the beginning and ending of the thing to make the triple, otherwise, the string is used as is (and only a single mtext will be created).

The tests are updated to take these changes into account.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.66%. Comparing base (efcdd46) to head (85abf0b).
⚠️ Report is 64 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1345      +/-   ##
===========================================
- Coverage    86.72%   86.66%   -0.06%     
===========================================
  Files          337      338       +1     
  Lines        84145    84269     +124     
  Branches      4769     3153    -1616     
===========================================
+ Hits         72971    73032      +61     
- Misses       11151    11237      +86     
+ Partials        23        0      -23     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[zorkow]

I would suggest to always consider tags to be a triple of strings [left, tag, right]. If one does not need the fences, once can leave them empty. This would avoid a all the case analysis for Array and would also simplify types.
Is there a reason why we would not want that?

[dpvc]

Is there a reason why we would not want that?

That would be a potential breaking change, which we aren't supposed to make in minor versions. So this is for backward compatibility, mainly with the tagformat extension, which currently has the tag format being a string not an array of strings. This allows either one.

I suppose the breaking up of the string could be moved to the tagformat extension rather than here, if you like that better. But it will need to be done somewhere, so I put it at the lowest level so that in case there are other subclasses of Tag that are in use, they will still work. Probably not much chance of that, however, so moving the complications into tagformat is probably sufficient. Would you prefer that?

[zorkow]

Is there a reason why we would not want that?

That would be a potential breaking change, which we aren't supposed to make in minor versions. So this is for backward compatibility, mainly with the tagformat extension, which currently has the tag format being a string not an array of strings. This allows either one.

I had not thought about the potential breaking change. Makes sense.