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

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: https://github.com/musescore/MuseScore/pull/33958
• Review comment: https://github.com/musescore/MuseScore/pull/33958#discussion_r3475542228

Requested by: @rpatters1