refactor: pass generated options through `runtimeConfig`

[BobbieGoede]

🔗 Linked issue

❓ Type of change

• [ ] 📖 Documentation (updates to the documentation or readme)
• [ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
• [x] 👌 Enhancement (improving an existing functionality like performance)
• [ ] ✨ New feature (a non-breaking change that adds functionality)
• [ ] ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

Replaces #2734

I would still like to improve the type in ModulePublicRuntimeConfig so users know which values cannot be configured using runtimeConfig, for example those used during route generation, should I mark these @internal using JSDocs?

By using runtimeConfig to pass the generated options we can reduce the complexity of our generated options templates (#build/i18n.options.mjs and #internal/i18n/options.mjs) and will make it easier for us to add runtimeConfig support for options used exclusively during runtime (detectBrowserLanguage for example).

I had to add configLocales to the runtime config as locales was already used for runtime domain support, we should probably merge these configurations for v9.

📝 Checklist

• [ ] I have linked an issue or discussion.
• [ ] I have updated the documentation accordingly.

[kazupon]

I would still like to improve the type in ModulePublicRuntimeConfig so users know which values cannot be configured using runtimeConfig, for example those used during route generation, should I mark these @internal using JSDocs?

Yes! We should mark as @internal and summary note for developer.