Optional container images for building and running LTFS

Nobody has claimed this yet.

**Is your feature request related to a problem? Please describe.**

Hi — thanks for LTFS. I deploy it on hosts with tape drives attached, and what I
wanted was to build it once and then simply run it: hand the same image to another
machine, or to someone else, and have it work without them setting up a toolchain at
all. That is really what a container buys here — not building for many distributions,
but not having to build a second time.

**Describe the solution you'd like**

I have built a containerized Autotools environment and would like to ask whether you
would be interested in it upstream. It adds a `docker/` directory, one workflow, a
`.dockerignore`, and a short section in the top-level README — no deletions, and no
existing workflow, build file or source behaviour changes. `linux/amd64` only.

Each distribution produces two images by role:

| Role | Contents | Use |
| --- | --- | --- |
| `dev` | Full Autotools toolchain plus gdb, strace, ccache; compiles a mounted source tree | Building and debugging |
| `runtime` | No toolchain; `sg`, `file`, `itdtimg` backends | Deployment |

- **In-support** (both roles): Ubuntu 26.04 / 24.04 / 22.04, Debian 13 / 12,
Rocky Linux 10 / 9 / 8.
- **EOL** (`runtime` only): Debian 11 / 10 / 9, Ubuntu 20.04 / 18.04 / 16.04,
CentOS 7, Fedora 28.

24 images in total. **LTFS builds and works on all of them, EOL included.** The EOL
ones build from frozen distribution archives, and each enforces a glibc ceiling at
build time (2.17 for CentOS 7 up to 2.31 for Debian 11) so the binaries really do run
on those old hosts.

Those EOL images are **neither published nor built in CI**: their base OS gets no
security updates, and their frozen archives do occasionally move or disappear — which
is something the person building one needs to see, not something a weekly red run
would help with. Their definitions are still linted, so a broken one cannot reach
them.

Since nothing automated watches them, they are verified by hand and the commit is
recorded. All eight built and passed their own self-test at
`3a8ac9bfe5bec69112f214b1b10fcc1815cd12f2`, and each image carries that revision in
`/usr/local/share/ltfs-autotools/build-revision`, so any image can say for itself
which source it came from.

Every image validates itself as it builds. Building `dev` compiles the source in a
throwaway stage, and only a pass marker naming the revision is carried forward — the
source tree never lands in the image. Building `runtime` runs a smoke test and formats
a virtual tape through the `file` backend, and the build fails if either does.

**I also tested this on real hardware**, since a green `file`-backend build says little
about the `sg` path. On an IBM ULTRIUM-HH8 (LTO-8) I ran the `runtime` image end to end:
enumerate the drive over `sg`, `mkltfs` a real cartridge, mount via FUSE, write 1 MiB,
unmount cleanly, remount in a fresh container, and read it back byte-identical.
`ltfsck` reports the volume consistent.

**Describe alternatives you've considered**

Keeping it in my own fork, which works fine — I am offering it because the
per-distribution build problem seems common. I am also happy with a smaller scope
(fewer distributions, or `runtime` only) if you prefer.

**Additional context**

- Two small fixes are needed for the images to build and I would include them:
`ltfs_ordered_copy` uses an f-string (breaks on the Python 3.5 in older bases), and
`configure.ac` finds `dlopen` only because net-snmp pulls in `-ldl`. Happy to send
them separately.
- Nothing needs to be published — the workflow validates without pushing anywhere.
- **It does cost Actions minutes**, and I would rather you set the budget than have me
guess: as written it fans out one job per in-support distribution on every push and
pull request, plus a weekly run to catch base images drifting. EOL images are not
built at all. Narrowing this further — pull requests only, or weekly only — is a
two-line change, so please say what suits you.
- Distribution differences live as data in one Bake file, so adding a release is a few
lines, not a new Dockerfile.
- Found while testing this but not caused by it, and I will report it separately:
`ltfs -a` segfaults when `LANG` names a locale the system has not generated —
libfuse's iconv module calls `strdup(setlocale(LC_CTYPE, ""))` unguarded while
printing module help, and `ltfs -a` reaches it through `fuse_main()` in
`src/main.c`. Nothing about it is container-specific — generating the locale makes
it go away and removing it brings it back. `ltfs -h` is unaffected.

The work is on a `feature/docker` branch and I can open a PR against `release/v2.4.9.0`
whenever suits you. Thanks for taking a look.

Start by reviewing the feature/docker branch, its docker/ directory, workflow, .dockerignore, and top-level README, then inspect the mentioned ltfs_ordered_copy and configure.ac fixes. Confirm the agreed image scope, CI budget, self-tests, revision markers, and documentation before considering the work done.

Written by the indexing model from the issue text.