[website] Add support to internationalization

[fellyph]

Motivation for the change, related issues

This pull request introduces comprehensive internationalization (i18n) support throughout the Playground website UI by integrating translation functions into user-facing strings. The changes ensure that all visible text, labels, and messages can be easily localized, improving accessibility for non-English users. The implementation leverages the @wordpress/i18n package and a custom useI18n hook to provide translation capabilities in React components.

Related to issue ##1991

Key changes include:

Internationalization Implementation:

• Added @wordpress/i18n as a dependency in package.json to enable translation functions.
• Introduced the useI18n hook and imported it into all relevant components to access the translation function (__).

UI String Localization:

• Replaced all hard-coded user-facing strings in components such as AddressBar, BrowserChrome, EnsurePlaygroundSiteIsSelected, ErrorReportModal, ImportFormModal, ImportForm, and LogModal with calls to the translation function (__). This covers aria-labels, modal titles, button labels, error messages, and instructional text.

These updates lay the groundwork for translating the Playground UI into multiple languages, making the application more accessible and user-friendly for a global audience.

Testing Instructions (or ideally a Blueprint)

1. Pull the branch locally
2. Run the applications npm run dev
3. Open the website with the selected language, for example:

• http://127.0.0.1:5400/website-server/?language=es_ES
• http://127.0.0.1:5400/website-server/?language=pt_BR
• http://127.0.0.1:5400/website-server/?language=en_GB

And check the UI:

Spanish UI

Brazilian Portuguese UI

[brandonpayton]

Thank you for making this, @fellyph!

After visually scanning this PR and reminding myself how various bits work around i18n, I think this looks pretty good overall. I have one question and one comment.

How will we extract new strings for translation when the UI is updated? There is a WP-CLI command for helping with these things, but for Playground which uses Node.js-based tooling, maybe a package like node-gettext would be more appropriate. Either way, I think we should add scripts for extracting these strings as part of this PR. (maybe I even missed that there are already such scripts)

On the treatment of individual strings:
AFAICT, the __() is mostly (or maybe entirely?) what is used in this PR, but I suspect translators will find many of the strings ambiguous or unclear without additional context provided by something like _x() or /* translators: ...*/ comments.

I think it would probably be better to merge this PR before taking the time to improve how the strings are presented to translators, but it would be helpful to make a follow-up PR immediately afterward to add string context where needed.