Many fixes, come inside for a better explanation

[Lord-Kamina]

First, sorry for an idiotically big PR... I began working on this when our workflows at https://www.github.com/performous/performous broke recently.

This is part of a larger effort to give whoever steps up as maintainer (I'm not it!) an all-around easier time. It partly relies on other PRs I have submitted at https://github.com/AppImageCrafters/AppRun and https://github.com/AppImageCrafters/tests-env

Here, I have done a number of changes:

1. I have fixed the testing suite.
2. I have added two environment variables:

• APPIMAGE_BUILDER_PY_VERSION: This will be set automatically when running the script, and it's populated from sys.version_info. The idea is to use this in python recipes, and then you don't need to update them when there are updates to python.
• APPIMAGE_BUILDER_REMOTE_REPO_OWNER: This will hold the repository-owner for any parts of the code that download or reference things from other repos. The idea is if somebody forks all three repos (appimage-builder, AppRun and tests-env) they can still have CI working on their forks. It's populated from the environment in __main__.py (and the CI workflows by default set it to ${{ github.repository_owner }}, with appimagecrafters as a default fallback.

3. Modernize the python project by updating all requirements and getting rid entirely of the setup.py, migrating completely to pyproject.toml
4. Fixes a few things in the appimage-builder and bash recipes.
5. Many fixes and refactoring to the actions workflows, which will result in you having a saner and working CI pipeline again.
6. I was working on fixing the compression thing in parallel to what got merged, it seems. I am making a change to that as well by defaulting to zstd because, according to the AppImage team, that should be the standard, as per XZ compression is broken #378

Below I will paste my explanation to a teammate of why I had to change some things in AppRun, as well as the structure of symlinks.

[20:45]Lord Kamina: The reason my builds were failing and the old ones are working is because the "compatibility" runtime is broken
[20:51]Lord Kamina: The way the compatibility thing works is, it bundles the glibc from the build machine in the AppImage
[20:52]Lord Kamina: And at runtime it compares the bundled and host glibc versions
[20:53]Lord Kamina: If the system's is newer, it uses that and if not it uses the bundled or "compatibility"
[20:53]Lord Kamina: But the compat version is broken for ubuntu at least
[20:54]Lord Kamina: Because ubuntu expects the ld-linux linker to be in /lib64
[20:55]Lord Kamina: And that symlink is not created by appimage-builder because it's a pretty non-standard location
[20:56]Lord Kamina: So you try to fire it, it can't find it and it fails with the "no such file error", which is just strerr(ENOENT)
[20:58]Lord Kamina: The reason the old appimages work is because they have ancient glibc versions so it just selects the normal os runtime
[20:58]Lord Kamina: But there's a bug in the comparison, it compares if system > bundled
[20:59]Lord Kamina: So when they're the same, it tries to use the broken bundled runtime, and that's why our CI was failing

This will probably take a while to digest and be reviewed properly but I'm willing to answer any questions.
In the meantime, you can go over to my fork and see how the CI works and download what should be a working appimage-builder AppImage made with python 3.12