Proposal: Support Interleaved Words and Symbols in `mx::api` Directions

[rpatters1]

(Sorry for the LLM-written issue. It was easier than thinking. 🙄)

Need

MusicXML allows a <direction-type> to contain an ordered sequence of <words> and <symbol> children. mx::api should be able to preserve and write these mixed direction
markings.

The immediate need is expressive dynamics and performance text, for example:

<direction-type>
  <words>più</words>
  <symbol>dynamicForte</symbol>
</direction-type>

or:

<direction-type>
  <symbol>dynamicPP</symbol>
  <words>subito</words>
</direction-type>

These are visually and semantically ordered. Splitting them into separate directions, or preserving only the words, loses useful notation intent.

Current Gap

mx::core already supports this shape: DirectionTypeChoiceChoice can be either words or symbol.

mx::api currently exposes direction words, but does not expose a corresponding ordered item for this mixed sequence. The reader also skips symbols in this group, and the
writer batches words rather than emitting an interleaved word/symbol run.

Desired Capability

mx::api should be able to read, represent, modify, and write ordered word/symbol sequences such as:

  <direction-type>
    <words>più</words>
    <symbol>dynamicForte</symbol>
  </direction-type>

without losing the symbol or the ordering during an API round trip.

[rpatters1]

In looking further at this with my own two eyes, I am realizing that DirectionData may need a major refactor. It seems like a perfect use-case for std::variant. You could have

using DirectionTypeData = std::variant <
    TempoData,
    MarkData,
    WedgeStart,
    WedgeStop,
    OttavaStart,
    SpannerStart,
    SpannerStop,
    WordsData,
    ChordData,
    FiguredBassData,
    SegnoData,
    CodaData,
    RehearsalData,
    SymbolData, // added by me for this issue ;-p
>;

Then all you would need is one vector.

std::vector<DirectionTypeData> directionTypes;

And you could dispense with DirectionComponent and orderedComponents which look risky to me no matter how you slice it. The directionTypes would encode the order directly, so there would be no need for trickery to round-trip.

I certainly would not undertake a refactor like this myself without your blessing. I don't know what the ramifications might be both in-repo and for other clients.