[Task]: Automate l10n extraction and build using new repos

[diox]

Description

We're changing the way to automate l10n. See https://mozilla-hub.atlassian.net/browse/AMOENG-2641. We need to:

• Set up 2 separate repos: addons-server-l10n, addons-frontend-l10n. Locale files will live there under the same path they do now in their respective original repos
• Modify l10n extraction to commit to these repos instead
• File an issue to point Pontoon to these new repos instead of addons-server and addons-frontend
• Rescind write permission for Pontoon user to the original repositories.
• When building, for both addons-server and addons-frontend, automatically pull the .po files from the corresponding l10n repositories

Acceptance Criteria

• item 1

┆Issue is synchronized with this Jira Task

[diox]

File an issue to point Pontoon to these new repos instead of addons-server and addons-frontend

See https://mozilla-hub.atlassian.net/wiki/spaces/FDPDT/pages/183861372/Localization+Intake+Process#Other-Types-of-Requests

[diox]

Could split into addons-server and addons-frontend to make it easier.

[diox]

When pulling locales at build time, it's important to pull locales that match the contents of the release: For normal releases that will always be the case as they are made from master however cherry-picks, or anything that would cause a new build, shouldn't pull locales changes that happened since the release, because they might change or completely remove strings that have changed on master
but haven't changed yet in the release.

Example:

• We release YYYY-MM-DD with string "foo". We pull corresponding locales at build time.
• We remove the string "foo" in master. It is removed from locales.
• We release YYYY-MM-DD-1, a cherry-pick from release YYYY-MM-DD. We shouldn't just blindly pull the latest locales, it would remove the translation for "foo" that is still in this release.

In the current scenario, everything happens through the same git repos, new locales changes happen in master while the cherry-pick is on a detached tag, so we don't have this problem.

We need some kind of pointer to the locales repos frozen with the release. I don't particularly like git submodules but it seems it would work for this use-case, provided we also regularly update the submodule pointer automatically. We could also do that sort of thing manually.

[diox]

From quick discussion on this topic we don't think we change strings enough for the scenario highlighted above to be a problem, so we're leaning towards a simple script that pulls current locales even if strings might have changed in the meantime.