fix(packaging/windows): route SPANISHINTERNATIONAL to po/es.po - #64

Summary

Fixes #55. NSIS exposes two Spanish MUI variants — SPANISH (LCID 0x040a, "Spanish, Traditional Sort") and SPANISHINTERNATIONAL (LCID 0x0c0a, "Spanish, Modern Sort" / Latin America). Modern Windows and Wine both report es_ES as the Modern variant, so the installer's MUI auto-detect in installer.nsi routes those users to SPANISHINTERNATIONAL.

po-to-nsh.py only mapped "es" → SPANISH, leaving the SPANISHINTERNATIONAL LangString block at the English fallback. The hand-written ENGLISH baseline in installer.nsi then provided the displayed strings for every es_ES user — which is exactly the behaviour @cardpuncher and @ngosang reproduced (French and Turkish work, Spanish doesn't), and which silently neutralised the catalog work in 462b2e4.

Fix

One alias added to NSIS_LANG_TO_LOCALE so the generated .nsh emits identical Spanish strings for both NSIS variants:

NSIS_LANG_TO_LOCALE.setdefault("SPANISHINTERNATIONAL", "es")

After the fix, the generated installer_strings_generated.nsh contains a translated ${LANG_SPANISHINTERNATIONAL} block byte-equivalent to the ${LANG_SPANISH} block (verified locally by re-running po-to-nsh.py).

Why other locales weren't affected

Each other NSIS language registered in installer.nsi:118-184 maps 1:1 to a single aMule catalog. The other split NSIS pairs (PORTUGUESE / PORTUGUESEBR, NORWEGIAN / NORWEGIANNYNORSK, SERBIAN / SERBIANLATIN, SIMPCHINESE / TRADCHINESE) are already covered correctly because aMule ships distinct catalogs (pt_PT / pt_BR, nn, zh_CN / zh_TW) for the ones that have translations; the rest fall back to English as intended. Only Spanish has two NSIS variants serviced by a single aMule catalog.

Test plan

• CI green on this branch.
• Manual: in the next nightly installer, run with LANG=es_ES.UTF-8 wine aMule-...-Setup-x64.exe and confirm section names + descriptions are Spanish (reproducing the issue Windows installer is not translated #55 setup).