Stop committing generated .mo (and .po) files; generate them at build time

[jacalata]

The tabcmd/locales/*/LC_MESSAGES/tabcmd.mo files are checked into git today, and .po files are gitignored but still regenerated locally when someone runs doit localize. This has two problems:

1. Drift. The committed .mo files can - and do - go out of sync with the .properties sources they are built from. Before fix: fall back to English per-key when locale is missing a msgid #440 landed, a fresh doit localize against the tip of development regenerated all 11 locale .mo files with ~20 keys different from what was committed (mostly stale entries for old keys and missing entries for new keys added since the last regen). Users hitting the drifted keys would see stale translations or fall back to the raw key.

2. Reviewer noise. .mo diffs are binary and unreadable in PRs. Reviewers cannot see whether a .mo change matches its intended .properties change.

The check-mo-freshness workflow added in #440 catches drift at PR time by regenerating and diffing. That closes the immediate leak but keeps the underlying pattern of "generated file committed to git."

Better long-term: treat .mo (and if practical .po) like tabcmd/_version.py - generate them during pip install / packaging, .gitignore them, and stop tracking them. pyproject.toml can wire the generation into the build backend so wheels and pyinstaller bundles include them. Contributors then only edit .properties; no regenerate-and-commit dance, no drift possible.

Prior art: most Python i18n projects (Babel, Django, Flask-Babel) treat .mo as build output.

Rough plan

• Add a build step that runs doit localize (or the equivalent msgfmt invocations) at pip install / wheel build time.
• Verify pyinstaller still bundles the generated .mo files correctly (via --collect-data tabcmd.locales which is already in the spec files).
• .gitignore **/*.mo; git rm --cached the tracked ones.
• Remove the check-mo-freshness workflow (it becomes moot once nothing is committed to drift from).