[Project Fluent] Basic internationalization support (would close PR #2553)

[philtweir]

Alternative approach to #2553. Not closing that just yet, but keen for feedback either way.

After thinking about the discussion on the Forum, the biggest challenge is that a lot of small changes brings risk. This is a suggestion:

1. finalize this PR that only adds the machinery for Fluent (and an single "canary" string)
2. this change sits on top to add give MVP coverage of translatable strings (feature/i18n-support-fluent-basic)
3. a much bigger set is here https://github.com/philtweir/fork-atuin/tree/feature/i18n-support-fluent

Suggestion: tidy-up, PR and merge this to provide i18n support. Once that is in a release and there is no negative feedback and folks confirm that the single example works OK, then PR 2., which is roughly the minimal set of common translatable strings. Less than that, and there's too much English leaking through to get buy-in, any more and the PR is oversized.

NB: there is a commit in 2. with English translations - note that it covers the full set of changes in 3. so most of them can be ignored in the near-term (happy to split it in two parts - one for 2. and one for 3.).

This PR does not add any translatable strings except one. Changes 2. and 3. only translate the crates atuin-common and atuin-client, plus inspector.rs and interactive.rs in the atuin crate.

How to test

This PR has only one translatable string, to make sure it works and breaks nothing, as the main challenge is to get the machinery in without regressions. However, using https://github.com/philtweir/fork-atuin/tree/feature/i18n-support-fluent-basic, you can build and take the interactive search as a minimal test.

In this PR, the only visible change should be:

$ LANG=en-US atuin asdf
error: unrecognized subcommand '⁨asdf⁩' and no executable named 'atuin-asdf' found in your PATH

Usage: atuin <COMMAND>

For more information, try '--help'.

vs

$ LANG=en-GB atuin search -i
error: unrecognised subcommand '⁨asdf⁩' and no executable named 'atuin-asdf' found in your PATH

Usage: atuin <COMMAND>

For more information, try '--help'.

How translatability is implemented

Adding t!(...) everywhere appropriate, in some places accounting for static return values, and then progressively adding translations to *.flt files as people wish to (separately) PR.

Notes

• as t!(...) can take arguments (e.g. translate %{time} ago) it does not return &'static str so, for FilterMode, I used lazy_static and elsewhere, switched to String or otherwise worked-around.
• originally I leaned to rust-i18n as Project Fluent wants slug-like keys, and that would make PRs much bigger and hard to review, but this approach creates a more traditional gettext-like macro, which is less invasive (as recommended in the cargo-i18n docs) - this means a new atuin_macro package (if this is a hard no, please say and I will try new ideas!)
• I had some difficulty getting the crates to behave consistently independently (which was not previously an issue) but I have now centralized translation strings in a top-level ./i18n folder (this has a side-benefit/downside that the same string will be translated the same way in all crates)

Checks

• I am happy for maintainers to push small adjustments to this PR, to speed up the review cycle
• I have checked that there are no existing pull requests for the same thing

[philtweir]

This is an awkward example but maybe helps show where extra steps are required (e.g. a simple non-literal/const string would be wrapped by t!(..) and done)

[philtweir]

TODO: this seems to be a cargo-i18n issue that it cannot accept non-literal versions.

That said, running cargo i18n doesn't actually seem to be necessary.

[philtweir]

But might need an upstream change in cargo-i18n to fix :/

[atuin-bot]

This pull request has been mentioned on Atuin Community. There might be relevant details there:

https://forum.atuin.sh/t/internationalization/733/7

[philtweir]

(see below: if it is not easy to address the cargo-i18n issue then I'm fairly sure we can ignore it - either way will restore these before merge)