Refactor MNX build to use submodule-managed mnxdom and remove system fallback

[coderabbitai]

Summary

Refactor the MNX build integration to stop relying on the optional system-installed mnxdom path and instead use a repository-managed dependency flow (planned submodule-based approach).

Background

In #33958, the fetched mnxdom revision was updated to a newer upstream commit to support the schema/API surface now required by the MNX import/export code. The current MSS_USE_SYSTEM_MNXDOM path in src/importexport/mnx/CMakeLists.txt does not enforce compatibility with that same API level, but this cannot be cleanly resolved within the current build approach.

Per the PR discussion, the intended follow-up is to refactor the build so that mnxdom is handled via a submodule and the need for a system-installed fallback is removed.

Affected area

• src/importexport/mnx/CMakeLists.txt
• MNX build/dependency wiring for iex_mnx

Requested changes

• Refactor mnxdom integration to use the planned submodule-based build approach.
• Remove or otherwise retire the MSS_USE_SYSTEM_MNXDOM path if it is no longer needed.
• Ensure the build uses a single controlled mnxdom source that matches the API/schema requirements of the MNX import/export code.

Rationale

This avoids configuration-time ambiguity where a system package may not match the API level expected by the source tree, and it aligns dependency resolution with the intended long-term build structure.

Acceptance criteria

• iex_mnx no longer depends on an unconstrained system mnxdom package path.
• The build configuration documents and uses the repository-managed mnxdom dependency flow.
• MNX import/export code builds against the intended mnxdom revision/API surface without needing separate system-package compatibility handling.

Backlinks

• PR: MNX import/export changes for schema version 19 #33958
• Review comment: MNX import/export changes for schema version 19 #33958 (comment)

Requested by: @rpatters1

[rpatters1]

I have reviewed the mnxdom build and how it meshes with muse_dep. The latest changes I have made to mnxdom

• no longer have any dependency on the w3c-cg/mnx repo at config time or build time.
• allow for straightforward use of nlohmann_json and json_chema_validator from muse_dep.

It would be very helpful to have guidance from the team on where to insert mnxdom as a submodule. The options that occur to me are

• embedded inside src/importexport/mnx.
• inside third_party/mnxdom at the top level.
• at the top level parallel to other submodules.

I like the first option because it is self-contained in the mnx sandbox, but I dislike it because it is hidden. Yet though hidden it will potentially have consequences every time someone goes to rebase unrelated changes. The other two options imply a longer-term commitment to maintaining it as a submodule, but they are easy to find.

FWIW, I have seen some projects that put all submodules in a submodules directory at the top of the project. Then one of the latter two options might become more defensible. At any rate, guidance from the team would be most welcome.

[rpatters1]

I had a brainstorm and realized that we could use a vendored tarball and continue to use FetchContent for mnxdom without the need of an internet connection at build time. This would work by putting the tarball somewhere inside the MuseScore tree and then pointing FetchContent at the local file.

For me this might be a big win over submodules which cause such headaches with rebasing unrelated changes. But I'm willing to tackle any solution the team chooses.

As stated above, the latest mnxdom should no longer need the internet for its build when getting its 2 dependencies from muse_dep.