Import Finale's .musx file format

[XiaoMigros]

Made in collaboration with @rpatters1 over the best part of this year.

.musx file importer

This PR allows MuseScore to read Finale's .musx file format, used by Finale from version 2014 until its demise. As MuseScore hopes to win over users leaving Finale, this importer offers a way out without sacrificing existing score libraries. While MuseScore's MusicXML import from Finale has improved substantially over time, many visual inaccuracies are caused by the lossy export from Finale itself. This importer therefore has a focus on visual accuracy (over "good MuseScore behaviour" or playback).

Prefences for level of detail

Nonetheless, under Preferences there are various levels of detail provided for the user to choose from:

How to handle element positioning:

• Reset all positions to sensible MuseScore values
• Import only manually adjusted positions (default)
• Import all positions (inherit a visual copy of Finale appearance; mostly concerns tie directions and beam slants)

Conversion from Finale-native fonts to SMuFL symbols
Prior to v27, Finale did not incorporate the SMuFL standard and used a diverse assortment of fonts to cover musical symbols. Many MuseScore users may not have Finale and its fonts installed on their device, which is why the importer detects and converts most of Finale's symbol fonts to SMuFL equivalents. This is enabled by default. For powerusers who may wish to keep their original fonts (or be using SMuFL optional or MakeMusic-only glyphs), this can be disabled.

More options could be provided; with the new reset options in the format tab we haven't yet deemed them necessary.

Code quirks

The importer differs from other importers in that it layouts the score mid-import, several times. These calls are needed to compute the correct positions of various elements. Integration with the layouting code is kept minimal - only a small handful of methods are called from it - so any changes made to the engraving module shouldn't have much effect.
Two new dependencies are linked using FetchContent - fixed release versions can be created before merging this PR.

Features

The importer detects and imports the following:

• Notes, grace notes, tuplets
• Ties, l.v. ties, partial ties, ties spanning non-adjacent notes
• Beams and beam positions
• Instrument and note transposition
• Tablature notes and string data
• Barlines
• Staff brackets
• Staves, staff types, instrument changes
• Page layout: Page margins, system margins, distance between staves, page & system scaling
• Individual staff visibility (hide when empty)
• Articulations
• Tremolos
• Fermatas
• Notehead parentheses
• Ornaments
• Breaths & Pauses
• Chord lines
• Fingering
• Sticking
• Tempo text
• Dynamics
• Expressions
• Harp pedal diagrams
• Staff text
• Lyrics
• Header/Footer text, text in frames
• Score style settings
• Spanners: Hairpins, ottavas, slurs, glissandos, trills, etc.
• Score properties (metadata)
• Clefs
• (Custom) Key signatures
• (Composite) Time signatures
• System object staves
• Chord symbols
• Repeat barlines, markers, jumps, and voltas
• Arpeggios (single- and cross-chord)
• Chord brackets

Unit tests have also been provided.

Part scores and slur handle positions are currently not imported, but may be added at a later date.

• I signed the CLA
• The title of the PR describes the problem it addresses
• Each commit's message describes its purpose and effects, and references the issue it resolves
• If changes are extensive, there is a sequence of easily reviewable commits
• The code in the PR follows the coding rules
• There are no unnecessary changes
• The code compiles and runs on my machine, preferably after each commit individually
• I created a unit test or vtest to verify the changes I made (if applicable)

[rpatters1]

In the interest of full disclosure, there may be some need for an opinion from the MuseScore legal team on this. The xml inside a musx archive is obfuscated, and it must be de-obfuscated to be read. We are of the opinion that since we are only de-obfuscating user data (and cracking no copy protection), it is the user that controls whether we are allowed to do this, not MakeMusic. But jurisdictions differ, and We Are Not Lawyers.