Remove usage of Locale from LanguageDialogFragment & for audio language selection flow via options

[BenHenning]

This is a tracker issue for unchanged code that will soon be changed in upcoming PRs.

LanguageDialogFragment relies on Locale & it shouldn't. Part of removing this dependency involves properly piping audio language information from LocaleController & TranslationController to the fragment. Some artifacts that were developed before I decided to stop trying to solve this since it's not an immediate need:

arguments.proto:

// Fragment arguments for creating instances of LanguageDialogFragment.
message LanguageDialogFragmentArguments {
  // The current audio language selected by the user.
  OppiaLanguage current_audio_language = 1;

  // The list of languages that may be selected by the user.
  repeated SelectableLanguage selectable_languages = 2;

  // Represents a language that can be selected for playing audio.
  message SelectableLanguage {
    // The language to select.
    OppiaLanguage language = 1;

    // A human-presentable string representation of the language that can be shown on UIs to users.
    // This has already been localized appropriately for the given language (i.e. 'English' will
    // appear as 'English', but 'Arabic' will appear localized such as 'عربي').
    string language_display_name = 2;
  }
}

LocaleController.kt:

  // TODO: document that this returns the name of the specified display language in that language's locale (so that the name is always readable by a native speaker of that language.
  fun retrieveAudioLanguageDisplayName(language: OppiaLanguage): DataProvider<String> {
    val providerId = AUDIO_TRANSLATIONS_DISPLAY_LANGUAGE_DATA_PROVIDER_ID
    return retrieveAudioTranslationsLocale(language).transform(providerId) { locale ->
      // Compute an Android locale for the audio language if one exists, otherwise default.
      val androidLocale =
        androidLocaleFactory.createAndroidLocale(locale.localeContext, forceLocale = false)
      return@transform androidLocale?.getDisplayLanguage(androidLocale)
        ?: locale.localeContext.getDisplayLanguage()
    }
  }

OppiaLocaleContextExtensions.kt:

fun OppiaLocaleContext.getDisplayLanguage(): String {
  return languageDefinition.getHumanReadableMacaronicLanguageName()
    ?: fallbackLanguageDefinition.getHumanReadableMacaronicLanguageName()
    ?: getLanguageId().toMachineLanguageCode()
    ?: getFallbackLanguageId().toMachineLanguageCode()
    ?: "Unknown language"
}

private fun LanguageSupportDefinition.getHumanReadableMacaronicLanguageName(): String? {
  return when (language) {
    // Top-level languages should rely on the system locale to provide the name.
    OppiaLanguage.ARABIC, OppiaLanguage.ENGLISH, OppiaLanguage.HINDI, OppiaLanguage.PORTUGUESE,
    OppiaLanguage.BRAZILIAN_PORTUGUESE -> null
    // TODO(#52): Consider moving this to an untranslated strings.xml file.
    OppiaLanguage.HINGLISH -> "Hinglish"
    OppiaLanguage.LANGUAGE_UNSPECIFIED, OppiaLanguage.UNRECOGNIZED, null -> null
  }
}

private fun LanguageId.toMachineLanguageCode(): String? {
  return when (languageTypeCase) {
    LanguageId.LanguageTypeCase.IETF_BCP47_ID -> ietfBcp47Id.ietfLanguageTag
    LanguageId.LanguageTypeCase.MACARONIC_ID -> macaronicId.combinedLanguageCode
    LanguageId.LanguageTypeCase.LANGUAGETYPE_NOT_SET, null -> null
  }
}

& a bunch of changes will be needed throughout AudioViewModel & the audio selection UI. The above was a work-in-progress, but my thinking is that we probably want to introduce a VoiceoverTranslationContext through EphemeralState that contains plug-and-play contexts for content & feedbacks. This can significantly simplify the audio view logic since it doesn't need to make any decisions about language selection or fallbacks (which really ought to be done by the translation system), and it provides an easy place to carry along the display language context that we're trying to replace per LanguageDialogFragment's Locale dependency.