Come up with an i18n strategy

[zenhack]

We'd like tempest to be internationalized from very early on. We should figure out what this is going to look like.

Things to look into:

• Are there any good libraries we can use from Go? Are they going to be a good fit for the client-side wasm environment (e.g. small code size)? I wouldn't be surprised if we ended up being better off rolling some things ourselves, or just wrapping browser APIs.
• How are we going to go about translations? Ideally we'd design this so that tempest can be translated with stuff like weblate; we should figure out what constraints we need to follow for that to happen.

[zenhack]

Reference for browser APIs around this: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl

It does seem like the Go libraries are going to be too bloated to use in the browser -- hard to avoid in a library that has extensive unicode support. We'll probably end up writing thin wrappers around the browser APIs instead then.

It looks like weblate is fairly flexible wrt. the formats it can import & export.

[zenhack]

I pushed a simple change to let us at least write internationalized UI strings; no way to actually supply an alternate localization, but when we do we won't have to hunt through all of the code to internationalize everything.

The new internal/browser/intl package lets you do things like:

l10n.Fmt("Hello, %0!", name)

where l10n is of type intl.L10N; it will translate the format string into the target locale and then splice in the arguments.

At some point we can write a tools that will:

• Find all the places we supply a format string, and extract them for translation
• Import translations so we can construct an L10N from them to use.

This shouldn't be too complicated.