api: expose ending display text and multiple ending numbers

[rpatters1]

What

MusicXML <ending> carries two pieces of information that mx::api does not expose:

1. All the pass numbers. The number attribute is a list — number="1, 2, 3" means the ending
   is played on passes 1, 2, and 3. mx::api::BarlineData has a single int endingNumber, and
   MeasureReader::parseBarline keeps only values().front(), so every number after the first is
   discarded on read and cannot be authored on write.
2. The displayed label. The <ending> element's text is the label drawn under the ending line,
   used when it differs from the number attribute — an ending played on passes 1, 2, and 3 is
   commonly labeled 1-3. mx::api has no field for it; neither the reader nor the writer touches
   mx::core::Ending::value().

MusicXML also allows a blank ending (number="") for the case where an ending is known to be
present but its passes are not. mx::api has no way to say that either.

Why

mx::core already models all of this correctly — Ending::number() returns an EndingNumber
holding the full list, and Ending::value() holds the label. The information is available and is
being thrown away in mx::impl on the way to mx::api.

A single volta covering several passes is ordinary notation, not an edge case, and notation programs
routinely let the user override the printed label. Today mx::api can express only the structural
start and stop of an ending plus one pass number, so both reading and authoring lose correct repeat
information: a 1-3 volta reads back as ending 1, and there is no way to author one at all.

Round-trip is affected as well: data/lysuite/ly45f_Repeats_InvalidEndings.xml uses
number="1, 2, 3" and cannot survive the api round-trip today.

Notes

Expect this to be a breaking change — BarlineData::endingNumber is a public int and representing
a list of passes changes its type. Design to be worked out separately.

Scoped to the number attribute and the element text. The remaining <ending> attributes
(print-object, end-length, text-x, text-y, font-*, color, system) are modeled by
mx::core but not mx::api; that is a separate enhancement.

References

Same layer and shape as #271; field-shape rationale in #249.