Build releases for more Linux targets

[EliahKagan]

This builds more *-unknown-linux-* targets in the release workflow, but still all only for max-pure.

This is the (kind of) change suggested in #1498 (reply in thread). Based on the subsequent comment discussion, such as #1498 (reply in thread), I had hoped also to build at least the *-linux-gnu targets for multiple features rather than just max-pure. But while that should be done, I have omitted it from this PR, because it is not as easy as I had hoped. This is because, when using cross, extra steps have to be taken to build against OpenSSL even where musl is not involved and a build with the same toolchain and target would ordinarily succeed, due to cross-rs/cross#229.

A number more targets could probably be added, at least for max-pure as here, without any special effort. However, for now I have limited it to targets for which I feel there is a specific justification. This divides into two cases:

• Targets for architectures that are commonly used. As a proxy for this, I included all the architectures that the latest LTS of Ubuntu (24.04) supports officially (including official ports but not unofficial ones). I also included i686 (32-bit x86), which Ubuntu does not support installing the operating system itself on anymore, but which I consider quite significant.

  Independently of this, I would have included aarch64 and s390x anyway. The other reasons to include aarch64 are that is widely available including in cloud compute services (second to x86-64), we are already building for it on Windows and macOS, and it has been requested explicitly. The other reason to include s390x is that it is currently the most prominent big-endian architecture, and having big-endian builds is useful since, through their use, bugs related to incorrect assumptions about data representation are often discovered.

• Targets for architectures we already had builds for, for whichever of *-gnu or *-musl (or *-gnueabihf or *-musleabihf) we did not have.

  Note that the additions for arm-* at this point are solely for this reason. No new 32-bit ARM architectures are added, and I am unsure if there should be other 32-bit ARM targets in addition to or perhaps even instead of the current ones. Maybe it would be better to build for armv7-* rather than arm-* targets. Maybe we should have non-hard-float ARM builds. Maybe we should include all architectures, ARM or otherwise, that some other popular Rust projects such as ripgrep build releases for. But I have deliberately omitted any such changes from this PR.

A few notes:

• Some targets have only *-gnu and not *-musl because no corresponding *-musl Rust target currently exists. But that is the only circumstance under which the release workflow, as it stands here, builds for *-gnu and not *-musl.

  Therefore, if the "provide *-musl builds for all *-gnu builds" request in #1242 is interpreted weakly, this completes that item. If it is interpreted strongly, however, then it will have to wait on the creation of more Rust targets than currently exist.

• I had originally hoped to add more non-MSVC Windows targets here, but that didn't work out. Some signs of it remain in the commit history so I (or anyone) who works on this may be reminded of what was attempted. It should be possible in the future, if it looks like it is worthwhile.

• The target for the riscv64 architecture is unaffected by http://rust-lang/libz-sys#200 because, being a Linux target, it is currently only building max-pure, which does not use the affected library.

Here's a workflow run for these changes, and here's an examination of the generated release archives. Usually I have been doing these examinations on Windows, but here the build I was most worried about was the RISC-V one, so I did it on a risc64 Ubuntu 24.04 LTS system, including running gix clone on both an SSH and HTTPS URL.

[Byron]

It's amazing to see the breadth of platforms gitoxide can now run on, max-pure or not, and I am amazed by the work that inarguably went into figuring all this out. Thank you very much 🙏.