feat: ending numbers and display text in mx::api

[rpatters1]

Human Summary

An ending bracket can cover more than one pass, and its printed label is not always just
its numbers: a volta played on passes 1, 2, and 3 is sometimes drawn 1-3. The label
need not be numeric at all; to continue is an example.

This PR permits a client to author and read every pass an ending covers, along with
whatever label is printed under the bracket, through a new optional BarlineData::ending.

Summary

MusicXML's ending element carries a list-valued number attribute, the passes the ending is
played on, and an element text body holding the printed label, which the spec uses when that
label differs from the numbers. mx::core::Ending models both, as an EndingNumber wrapping a
vector of ints and a string value, but mx::api dropped all of it: BarlineData carried an
EndingType and a single int, so MeasureReader::parseBarline kept only the first value of the
number list, and neither direction ever touched Ending::value().

Both fields are replaced by one std::optional<EndingData> ending:

• EndingData::numbers is the full list of passes. Empty means a blank ending, MusicXML's way
  of saying a bracket is present but which passes it covers is unknown, a state the old int could
  not express since 0 meant unspecified.
• EndingData::text is the printed label. Left empty, the writer emits no text node and the
  ending displays its numbers, so authoring without a label produces the same XML as before.

EndingType::none is removed. Presence is now the optional itself, so the enum's three values
match Converter::endingMap one for one, and an ending can no longer exist carrying a type that
says there is no ending.

Breaking: BarlineData::endingType, BarlineData::endingNumber, and EndingType::none are
removed from the public api.

The writer always sets the number attribute, which the schema requires; an empty list serializes
as number="". Converter gains the reverse core::StartStopDiscontinue to api::EndingType
conversion, which replaces a hand-written switch in the reader with the existing bridge table.

The repeat fields on BarlineData are deliberately untouched. An ending and a repeat are
independent children of the same barline and routinely share one, but repeat remains a bare
bool with flat siblings; reshaping it is a separate breaking change (#249).

lysuite/ly45f_Repeats_InvalidEndings.xml is now pinned (363 -> 364). It failed the strict
compare on exactly this gap, expected number=1, 2, 3 against actual number=1, and is the only
file whose status changed across the 838-file corpus. data/synthetic/ending.3.0.xml and
ending.4.0.xml still fail on the ending attributes mx::api does not model: print-object,
end-length, text-x, text-y, font, color, and system. Neither is pinned. No new corpus files, so
no pinned-count or audit regeneration.

Testing

• Seven new cases in RepeatApiTest: multi-number round trip with a label, exact serialization
  of number="1, 2, 3" and the text node, the read path, an ending with no label, a blank ending,
  absence, and a read of the data/synthetic/ending.3.0.xml shape whose text body differs from its
  number
• Full api suite passes (5921 assertions in 528 test cases)
• make api-roundtrip passes (364 of 364 pinned)
• make core-roundtrip-test passes (839 test cases)
• make core-unit passes (212 assertions in 41 test cases)
• make fmt-check clean on touched files

References

• Closes api: expose ending display text and multiple ending numbers #387
• Same area as api: round-trip drops repeat times attribute #271, which added BarlineData::repeatTimes to the sibling repeat element
• Field-shape rationale for leaving the repeat fields alone is in api: replace value + isSpecified bool pairs with an explicit optional value type #249