fix: keep custom language keys in the resolved translations

[mcanouil]

Closes #14772.

translationsForLang rebuilt the language table from an allow-list and ran after the user's language object was merged over the defaults, so a key Quarto does not ship was accepted by the schema, merged, then discarded before templates saw it.

• translationsForLang now also copies non-object values it does not recognise; locale variations are objects, so they stay out and the variation loop below keeps merging them itself.
• Custom keys prefixed callout-, crossref- or environment- now also reach Lua filter params, and search- keys reach website search options, because both consumers select by prefix over the whole table.
• There is no namespacing convention, so an extension key can collide with a key Quarto adds later. User values are merged over the defaults, so the extension's value still wins in its own documents, but requiring a prefix is an option if that is not acceptable.
• Side effect: a string added to _language.yml without a matching entry in kLanguageDefaultsKeys is no longer dropped as a built-in default.
• Possible follow-up, not done here: derive kLanguageDefaultsKeys from _language.yml at build time, so the YAML file, the constants array and the schema cannot drift.

The test renders one Typst document through a typst-show.typ partial and reads back four keys: the custom key, an override of a built-in key, an untouched built-in key, and a key supplied through a locale variation.

[posit-snyk-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.