feat: check ID uniqueness and ID references

[webern]

Human Summary

Checking the global uniqueness of IDs is pretty awkward for mx, so we do it during parses and writes, but not during dom interactions.

In keeping with the design philosophy, we coerce duplicate IDs into unique ones if encountered, but at least now we have a mechanism for raising a diagnostic warning when we do.

Summary

MusicXML types an element's id two ways. An xs:ID has to be unique in the whole document; an
xs:IDREF has to match an xs:ID somewhere in the same document. mx::core models both as
Token, which keeps a value a legal name but cannot see the rest of the document, so neither rule
was checked anywhere.

Three things followed from that.

Token repair can manufacture a collision. It strips illegal characters, so two ids that differ in
the file can come out identical. The import diagnostic already warned that "the repaired ID may
duplicate another ID in the document" without anything ever confirming or denying it.

A dangling reference was imported in silence. ScoreConversions.cpp checks that a <part> resolves
to a <score-part>, but only on the timewise path, so a plain score-partwise read never ran it.
data/lysuite/ly41h_TooManyParts.xml declares one <score-part id="P1"> and then parts P1, P3
and P4. We imported it without a word.

getCoreDocument() hands out a mutable reference to the core DOM, and the header carried a standing
TODO about the ID loophole that opens. A check living in mx::impl would miss that caller entirely.

What this adds

One pass over the raw pugixml tree, in mx::core, run at both document seams. It is in core because
that is where the schema is modelled, so it is available to code using mx::core directly and it
covers the getCoreDocument() escape hatch, with nothing duplicated in mx::api.

Values are compared after Token repair, since that is what the parsed document holds. The two
directions differ on purpose:

• Reading reports and changes nothing. Renaming on import would break the parse/serialize round
  trip, and the caller is owed fidelity to the file they handed us.
• Writing renames a duplicate so we do not emit an invalid document. The first element to claim an
  id keeps it, later ones are renamed, and references are left pointing at the first, because
  nothing in the document says which was meant.

Both report at warning, since the result stays usable. Two new diagnostic codes, duplicateId and
danglingIdReference, because a caller may care about one and not the other. writeToFile and
writeToStream gain a Diagnostics & overload, which every other public entry point already had.

Classifying an attribute needs a table of which element and attribute pairs are xs:ID and which
are xs:IDREF. That table is hand-written in core, and IdSchemaDriftTest re-derives it from
docs/musicxml-4.0-ed15c23.xsd and fails if the two disagree. So there is drift protection without
touching gen/.

Checking that a reference names the right kind of element, a <part> naming a <score-part> rather
than any id at all, is stronger than XSD can express. The schema declares no xs:key or xs:keyref
and states the targets only in its documentation, so those twelve are supplied by hand, with a
comment for whoever extends them.

Not in scope

The xlink:href fragment on <link> that names a <bookmark>, which the schema types as
xs:anyURI. And the synthesized <score-instrument> id in PartWriter.cpp, which writes a
reference that does not match the definition it creates. That one is #445, and this pass will start
reporting it once #445 lands.

Testing

make fmt-check and make test-all on this branch:

Suite	Result
core round-trip	2 assertions in 841 test cases
core unit	603 assertions in 69 test cases
api	5879 assertions in 657 test cases
api round-trip	414 passed, 0 failed of 414 pinned

src/private/mxtest/api/roundtrip-baseline.txt is unchanged, which is the point: reading reports
and does not touch the document, and nothing in data/ has a duplicate id for the write side to
rename.

New tests, 17 in all:

• IdIntegrityTest, 12 cases over the core pass: a clean document, a duplicate, a duplicate across
  two different element kinds, a collision that only Token repair creates, a dangling reference, a
  reference naming the wrong kind of element, a reference naming the right one, that reading changes
  nothing, that writing renames and skips a name already used later in the document, that writing
  reports a dangling reference without changing it, and that writing still renames when no handler
  is listening.
• IdSchemaDriftTest, 2 cases, re-deriving the table from docs/musicxml-4.0-ed15c23.xsd: 65
  xs:ID element names and 12 xs:IDREF element names, each element named once, and every
  reference carrying a target.
• DiagnosticsTest, 3 cases at the api seam: a duplicate id and a dangling reference reported from
  fromStream, and a duplicate renamed by writeToStream.

Scanning all 1698 files under data/ for what the new pass would say: 0 duplicate ids, 0 references
to the wrong kind of element, and 14 dangling references in 13 files. Two of those are the
ly41h_TooManyParts.xml parts described above, one is musuite/testPartsSpecialCases.xml, and the
other eleven are single-element fixtures that carry a reference with no document around it. All
warn, none fail.

References

• Closes ID uniqueness is not constrained by mx::core. #397
• Part of Support spanners specified as a single object instead of start and stop pairs. #393
• Related to a synthesized score-instrument id is process-global and leaves midi-instrument dangling #445