[ftr] Add METS/MODS export for MEI source files

[hizclick]

Is your feature request related to a problem? Please describe.
The edition example only ships MEI source files (content/sources/edirom_source_*.xml) with facsimile <surface>/<zone> data and <measure facs="#zone"> links. There is no way to expose this data as METS/MODS, which is the format expected by library viewers (e.g. DFG-Viewer, Kitodo-based presentation systems) and is needed to make Edirom sources interoperable with those tools. The repository already contains a reference pair (mets_M001.xml / V0001.mei) showing the target shape, but no tooling to actually produce such a file from our own MEI sources.

Describe the solution you'd like
Add an XSLT stylesheet that converts an Edirom source MEI file into a METS/MODS document following the mets_M001.xml model:

• dmdSec (MODS): title, composer and identifiers, built from the source's own manifestationList/manifestation plus the linked work file (resolved via relationList/relation[@rel='isEmbodimentOf']/@target).
• fileSec: one file per <surface> (DEFAULT/MAX/THUMBS derived from the IIIF graphic/@target), plus a SCORE file group pointing at the MEI file itself.
• structMap TYPE="PHYSICAL": one page div per <surface>.
• structMap TYPE="MUSICAL": for every <measure facs="#zone">, an <area> with the zone's pixel COORDS on its page image, plus a BEGIN/END IDREF area pointing at the measure's own @xml:id in the SCORE file — mirroring how mets_M001.xml links facsimile regions to MEI measures.
• structMap TYPE="LOGICAL": a single div, with @TYPE inferred from the source siglum (Ms… → manuscript, Pr…/Dr… → print).

This has been implemented in xslt/mei-source-to-mets.xsl (requires an XSLT 2.0+/3.0 processor such as Saxon) and validated against both sample sources in content/sources/ (see mets_edirom_source_2b2b26e5.xml for a generated example). Institution-specific data that can't be derived from the MEI (rights holder, published score URL, IIIF suffixes) are exposed as stylesheet parameters with sensible fallbacks.

Describe alternatives you've considered

• Hand-authoring METS/MODS per source, as was done for the mets_M001.xml reference file — not maintainable and out of sync with the MEI as soon as the source changes.
• Deriving METS only from facsimile data without the MUSICAL structMap — rejected because the measure-to-facsimile linking is a core Edirom feature and is exactly what viewers like DFG-Viewer/Da Capo need to display correctly.

Additional context
See xslt/mei-source-to-mets.xsl for the implementation and mets_edirom_source_2b2b26e5.xml for a sample output generated from content/sources/edirom_source_2b2b26e5-c85d-4edd-8806-fe126ce390a2.xml.

[hizclick]

One thing I'd like feedback on: for the optional rights/owner block in edirom.mei2metsmods.xsl, I used a custom ed: namespace (http://www.edirom.de/) — ed:rights, ed:owner, ed:ownerLogo, ed:ownerSiteURL, ed:ownerContact — instead of the dv: namespace (http://dfg-viewer.de/) that mets_M001.xml (our SLUB Dresden reference example) uses for the same purpose.

My reasoning was that dv: is specifically DFG-Viewer's own extension namespace, and it felt presumptuous to use it for METS we're generating ourselves, independent of whether it's ever consumed by an actual DFG-Viewer instance.

Would appreciate input on whether to keep ed: or replace it with something else.