Set basic i18n framework

[gnprice]

Naturally we'll want the app to be internationalized and offer translations in many languages, just like zulip-mobile and Zulip web.

This issue is not for actually doing that. Rather this issue is for setting some of the code patterns we'll need in order to support that internationalization. Doing so sooner will be useful because it will affect many places in our UI code, and so the sooner we do it the fewer places we'll have to sweep back over to fix into the new pattern (and the more places we can instead write in the desired pattern in the first place).

Specifically, the scope of this issue is:

• We'll set up Flutter to localize its own UI elements, with flutter_localizations. (This is mostly observable when using a screen-reader or other accessibility tool.) See tutorial: https://docs.flutter.dev/ui/accessibility-and-localization/internationalization#setting-up

• We'll enable one or two other locales besides en, enough to demo the functionality.

• We'll internationalize a handful of our own messages: set our UI code to use a translated form of them, and set up the infrastructure for that code to find that form.

  The tutorial page seems to offer a couple of ways to structure this: the gen_l10n way where you write ARB files and a tool generates a Dart class, or the intl way where you write a Dart class and a tool generates ARB files.

  Both approaches lead to essentially the same idiom in UI code that needs a translated message: we'd write ZulipLocalizations.of(context).helloWorld, where that identifier helloWorld is a name we pick for the given message. So we can pick one approach, later decide we like the other better, and switch without scattering much if any disruption across the app code.

Out of scope are:

• Sweeping through TODO(i18n) comments and other places where we need to translate strings: Sweep through UI strings to internationalize #277

  This is a followup issue to do soon after, though.

• Internationalizing dates, times, or other aspects beyond translating messages. For dates and times, that's Internationalize dates and times in UI #278. If we see other such aspects, we can file followup issues for them.

• Handling RTL layouts. See Experiment with RTL layout #77.

• Wiring up the ARB files to a service where Zulip's volunteer translators can contribute translations: Wire up to a platform for contributing translations #276

  This will be a bit of a project because it's coupled with Zulip migrating off of Transifex to some other service in this category. For details, see issue.