move the linux wheel builds to manylinux_2_28

The linux wheels build on `manylinux2014`, whose CentOS 7 base predates every native toolchain need this project has grown. Getting 0.5.0 to build there (#750, #751) required downloading protoc (distro version 2.5.0), installing libclang from an LLVM 7 software collection, and handing bindgen the library path and builtin-header include explicitly because the SCL layout defeats libclang's own resource lookup. The aarch64 step additionally carries `CFLAGS_aarch64_unknown_linux_gnu="-D__ARM_ARCH=8"` for ring, with a comment saying it can go once the image moves to 2_28.

Moving to `manylinux_2_28` (AlmaLinux 8) removes all of that except the pinned protoc download (the 8.x distro protoc is 3.5, still too old): the distro `clang-devel` is clang 21 and bindgen finds it with no environment handed in, and ring compiles without the CFLAGS workaround. Verified in `quay.io/pypa/manylinux_2_28`: `lance-encoding` 11.0.0, `librocksdb-sys` 0.16.0 and `ring` 0.17.14 all compile clean.

The cost is the wheel floor moving from glibc 2.17 to 2.28, dropping CentOS 7, Ubuntu 18.04, and Amazon Linux 2, all past end of life. In practice nothing is lost: pyarrow, numpy, and the datafusion python package, the packages hudi wheels run alongside, ship `manylinux_2_28` wheels only, so any environment excluded by the new floor already cannot install the surrounding stack.

Targeting 0.6.0: the 0.5.0 release ships from `manylinux2014` (#751) so the floor does not change mid-release, and 0.5.0 already raises the Python floor to 3.10, so the two compatibility changes land in separate releases.

No file or test is named in the issue. Start at the Linux wheel build entry point that selects manylinux2014 and compare it with the manylinux_2_28 environment described here. Done means the 0.6.0 wheels use the new image, retain the pinned protoc download, remove the clang and aarch64 workarounds, and compile the listed dependencies cleanly.

Written by the indexing model from the issue text.