Publish the sil-lift container image to GHCR

Inizia da Dockerfile, action.yml, .github/workflows/container.yml e docs/en/guides/lift-export-interop.md. Esamina il job esistente di build e smoke test, quindi aggiungi la pubblicazione delle release su GHCR senza eseguire il push da pull requests o fork. Il lavoro è completato quando vengono pubblicati i tag di release versionati e latest, viene documentato l’esempio Docker basato sul pull e i controlli delle PR continuano a eseguire la build e lo smoke test dell’immagine.

Background

The repo ships a Dockerfile, a Docker-based GitHub Action (action.yml), and a build-only CI check (.github/workflows/container.yml) so non-Python CI can run sil-lift validate — but no image is published. Consumers must build it themselves, the Action rebuilds the Dockerfile on every run, and there's no docker run ghcr.io/… path.

Proposal

Publish a versioned image to GitHub Container Registry (ghcr.io/sillsdev/python-sil-lift):

• Add a publish job (extend container.yml, or a new release-triggered workflow) that builds and pushes to GHCR using GITHUB_TOKEN with permissions: packages: write.
• Tags: vX.Y.Z plus a moving latest on each GitHub Release; optionally an edge/sha tag on pushes to main for interim testing.
• Keep the existing build + smoke-test check on PRs; don't push from PRs/forks.

Docs

• Update the Producing conformant LIFT guide (docs/en/guides/lift-export-interop.md) to show the pull path — docker run --rm -v "$PWD:/work" -w /work ghcr.io/sillsdev/python-sil-lift validate export.lift --strict — alongside the current build-from-Dockerfile example.

Optional follow-ons

• Point the Action at the published image (runs.image: docker://ghcr.io/sillsdev/python-sil-lift:<tag>) instead of Dockerfile, so uses: sillsdev/python-sil-lift@vX doesn't rebuild each run (do this together with the release tagging so the tags line up).
• Multi-arch build (linux/amd64 + arm64) via buildx/QEMU, if arm runners matter.

Non-goals

• No change to CLI/validate behavior or image contents.
• PyPI publishing (separate; handled by the release workflow).

Notes

• Versioned image tags only become meaningful once the first release is tagged; an edge tag on main can cover the interim.