i18n: Better LocalizationProtocol interface.

[elenakrittik]

Summary

Improve LocalizationProtocol to ease usage of more types of localization stores (not that Stores) for supplying localizations to disnake.

What is the feature request for?

The core library

The Problem

First, LocalizationProtocol requires implementors to build localization dicts on startup, but not all localization systems have all of the available localizations "at hand" (databases or on-demand loaders).

Secondly, it requires implementors to examine available languages themselves, forcing to use API in form of (key) -> { locale: l10n }, while most external localization systems use an API of form of (key, locale) -> l10n.

If not resolved by the programmer of LocalizationProtocol's implementation, second problem expands to the translator teams, because humans think in terms of (key, locale) -> l10n too. Let's imagine i'm a translator from source language (english) to russian. What i usually do is (abstractly): choose my locale (russian), choose the key to localize, and provide localization for it. Doesn't seem any good if i was forced to choose a key and then localize it for all locales, most of which i likely don't know. (a bit of drama, i know)

The Ideal Solution

Both problems can be resolved by changing LocalizationProtocol's .get() to be (key, locale) -> l10n instead, and (of course) updating all internal systems to use it. Not sure yet if this can be done in a compatible manner in regard to LocalizationProtocol implementors, but existing users of the default LocalizationStore will not be affected.

The Current Solution

"Problems" described above are (mostly) minor inconveniences, and can be worked around without relatively much hassle.

Additional Context

Related #1103

I am willing to submit a PR for this.