ModInfo i18n API

[MattSturgeon]

This PR provides a general i18n API to IModInfo that could be used in Neoforged to implement neoforged/NeoForge#639.

I've added a unit test to cover the new behavior, however (as a new contributor) I'm unclear on the best way to test the functionality in game.

That said, if these assumptions are correct, then everything should work as intended:

• The I18NParser implementation that uses I18NExtension will return the i18n key when a translation is not present.
• I18NParser's i18n map contains (at least) the same entries as Minecraft's Language instance.
• I18NParser's i18n map is updated by LanguageManager when the language is changed or resource pakcs are reloaded.

Using the API

Translations from mod display name and description can be provided by adding the following keys to lang files:

• "fml.menu.mods.info.name.[modid]"
• "fml.menu.mods.info.description.[modid]"
  Where [modid] should be replaced with the actual mod ID.

These can then be accessed using new methods added to IModInfo (names subject to change):

• IModInfo.getDisplayNameTranslated()
• IModInfo.getDescriptionTranslated()
  Which return the translated string (if one exists), or the string defined in mods.toml otherwise.

This could instead return an Optional or nullable value if preferred? That way you could easily check if a translated name/description exists and explicitly fallback using Optional::orElseGet.

Tests

I've added a unit test for the new behavior. In order to do so, I had to make some preparatory changes elsewhere, which I've kept to their own commits for clarity.

As unit tests, they cannot check the assumptions I outlined above.

[MattSturgeon]

I18nExtension#parseMessage (used by I18NParser) calls I18nExtension#parseMessageWithFallback with the i18n key set as the fallback. Therefore the first assumption is correct.

It'd be better if I18NParser provided a method accepting a fallback, as this PR would then be able to pass IModInfo::getDisplayName as the fallback supplier. Seeing as this PR breaks the FML API anyway, maybe that approach would be better. That approach would also make the test effectively pointless.

I18n#setLanguage is hooked into, so when the LanguageManager sets the language, I18nExtension gets updated. Therefore the last two assumptions are also correct.