VPN-6649 - Fix `Malmö` translation

[mcleinman]

Description

Malmö is the only city with special characters in the name. Our build scripts should handle this fine - and we use Servers.Malm for the string ID. It builds perfectly on my machine, but was failing on TaskCluster.

I've spent perhaps a bit too long trying to get the to the root of the problem, before I put up this hacky fix. Here is what I know:

1. In Localizer::getTranslatedCityName, we have the following values on my machine on main branch: cityName Malmö / parsedCityName Malm / i18nCityId ServersMalm / value Μάλμε. On TaskCluster (on main), we get the same ones with one exception - value is Malmö.
2. Digging deeper into how value is created here, this seems to imply it's an issue with the translation that Qt is pulling out.
3. Looking at how we build our translation files, we have this line being build on TaskCluster: <message id="servers.Malmö"> When building locally, I get the same thing. This is in build/translations/generated/mozillavpn_el.ts. This makes sense, as servers.Malmö is the string ID used in the translation repo.
4. After the .ts file is created in our build process, we use lconvert to convert it to a binary qm file. qm files are binary, and are somewhat of a black box to us.
5. It seems like somewhere in lconvert or loading the files when running the client, special characters should get stripped out from the translation ID. And they are on my machine, but not on TaskCluster. In both cases, what happens at this level is somewhat unknown, as they get deep Qt's handling of translations - it's deeper than our translation scripts (for creating translation files or loading them into the client).

The attached fix is hacky. I hate it. It's not generalizable. While we currently only have one server with a special character, if we ever got another one we'd need to replicate this fix for it. It's also deep in a build script, and is not immediately obvious where/how this is handled.

However, I chose this option for two reasons: A. We rarely add new servers, and thus the liklihood of adding a new server with a special character in the name is minimal. It may happen once every many years, but isn't something we'll deal with regularly. B. We could hackily change the string ID when pulling strings out into the translation repo. That would at least keep the ID as servers.Malm for most of the round trip journey from our client repo to the translation repo and back. However, this would mean that we'd lose the existing translation for Malmö, and translators would need to re-translate it under the new string ID. I wanted to avoid that.

Feel free to reject this PR, if you don't like the hacky solution here. I'm open to other methods, especially changing the string ID before it's sent to the translation repo (which comes with the downside of B above).

Reference

VPN-6649

Checklist

• [x] My code follows the style guidelines for this project
• [x] I have not added any packages that contain high risk or unknown licenses (GPL, LGPL, MPL, etc. consult with DevOps if in question)
• [x] I have performed a self review of my own code
• [x] I have commented my code PARTICULARLY in hard to understand areas
• [x] I have added thorough tests where needed