Allow custom i18n mechanisms

[tbouffard]

Is your feature request related to a problem? Please describe.

Currently, maxGraph provides its own built-in i18n mechanism, which is spread across multiple places in the codebase.
This implementation is static and cannot be customized, which can be problematic for applications that have their own translation system.

Additionally, because it is a global and static implementation, it gets imported into applications using maxGraph, even when not needed.
This negatively impacts tree-shaking, increasing the final bundle size unnecessarily.

The built-in maxGraph i18n mechanism involves:

• The Client object for configuration.
• The Translations class for handling i18n resources.
• MaxRequest to load remote resources.

Describe the solution you'd like

• Provide a way to globally configure i18n.
• Offer two built-in implementations:
  1. The existing mechanism.
  2. A lightweight alternative that disables i18n entirely (this should be the default to improve tree-shaking).
• Allow applications to plug in their own i18n mechanism easily.
• Continue to use the existing i18n mechanism in stories

This change will make maxGraph more modular and better suited for applications with custom i18n needs. 🚀

A proof of concept (POC) has been explored in PR #668.
It shows that the built-in i18n system adds a significant footprint to the minified bundle.
The POC also demonstrates a possible solution to make the i18n system configurable, inspired by the approach used for the logger configuration.

Describe alternatives you've considered

One alternative would be to allow overriding the existing Translations class, but this wouldn't solve the tree-shaking issue.
A proper configuration mechanism would be more flexible and allow applications to avoid including unnecessary code.

Additional context

✅ Preliminary Tasks

Implemented in #689 and #690:

• Ensure the current i18n system works as expected.
• Fix missing translations (e.g., constraint error messages currently display keys instead of translations).
• Language files should also be duplicated in the stories package (similar to images).
• Make i18n resources available in the npm package.
• Use these resources in Stories as an example.
• Add user documentation explaining:
  • How to use maxGraph i18n with the Translations class (currently documented in the API design for developers).
  • That resources must be copied into the application and how to do so.
  • Link to a Story demonstrating this with an example.
• Add additional i18n resources for FR and ES (see Issue #352).

✅ Tasks to Make the i18n Mechanism Configurable

Following the approach explored in PR #668:

• Improve the configuration of the existing Translations implementation: Introduce a TranslationsConfig object to move related configuration out of Client. feat!: introduce TranslationsConfig #691
• Implement a new configuration system allowing users to select their preferred i18n mechanism. feat!: introduce a way to configure the I18n provider #737