Tweak translations.json i18n logic to use the correct algorithm for translation discovery

Basically, we should be using the algorithm described in this doc for translations.json, but are not:

def get_language_translation_data(language: str) -> Dict[str, str]:                                  
    if language == "en":                                                                             
        return {}                                                                                    
    locale = translation.to_locale(language)                                                         
    path = os.path.join(settings.DEPLOY_ROOT, "locale", locale, "translations.json")                 
    try:                                                                                             
        with open(path, "rb") as reader:                                                             
            return orjson.loads(reader.read())                                                       
    except FileNotFoundError:                                                                        
        print(f"Translation for {language} not found at {path}")                                     
        return {}                                                                                    

Specifically, following the de-at (Austrian German) example from the docs, consider what would happen if we added a de-at locale directly alongside the de one, and it only changed 10 strings:

• The Django/backend translations would work correctly -- it'd detect de-at as the language, and serve strings from de-at (if present) or de (if present) or the default English (if no translation was available).
• However, all of zulip's frontend translations would see that de-at is the Django locale, and serve the de-at translations.json file, that only has 10 strings in it.

We we should be doing is, if the user has selected a country-specific locale like de-at, we read both the de-at and de (there may be a fancy Django function for splitting these, but I think split("_") is correct?) files, and basically overwrite anything in the de structure that's not the empty string in de-at.

This has no effect in Zulip currently because we don't have translations.json files for country-specific variants of languages, but we might have some soon.

I think we can probably manually test our logic by just doing some fake data setup in a development environment -- use manage.py makemessages --lang=de_at or something like it to create an empty data set for de_at, and then hand-add add like 2 highly visible strings, and then do compilemessages.

@hackerkid can you take this one?