Replace static-tools runtime with static reference implementation runtime

[Korne127]

This pull request replaces the static-tools runtime that's currently used for go-appimage with the new static runtime (https://github.com/AppImage/type2-runtime) that's now the official reference implementation runtime.
This ensures consistency with AppImages created with other AppImage creation tools and removes the dependency on the (now redundant) static-tools runtime.

It also improves the code calculating the runtime path by removing unnecessary (outdated) instructions.

[github-actions]

Build for testing:
artifacts
Use at your own risk.

[probonopd]

Thanks @Korne127.
I understand the intention of this PR, however I want to keep the build system in my private projects "lean and mean" (no Docker, no complications). So at least for some time, I'd rather keep the sources in sync rather than outright replace the whole runtime.

[Korne127]

Genuine question: What's less "lean and mean" about this? I'm curious as this pull request just replaces links without complicating the build system.

And related to that, what are the differences of the static-tools runtime and the reference one? I would have thought that the static-tools one is a predecessor or variant, and using the same reference runtime across projects would simplify everything (not having to maintain the same thing in two different repositories, AppImages guaranteed to behave consistently, etc.).

PS: Could you please take a look at AppImage/docs.appimage.org#102?

[probonopd]

Genuine question: What's less "lean and mean" about this?

https://github.com/AppImage/type2-runtime now contains Docker and I don't understand all of it. So in my own personal projects in https://github.com/probonopd I want to use something simpler, something I fully understand.

And related to that, what are the differences of the static-tools runtime and the reference one?

type2-runtime started out as the codebase from https://github.com/probonopd/static-tools but has been updated since. So it's a matter of backporting the changes (ideally, making the source code in static-tools identical to the one in type2-runtime).

[Korne127]

But wouldn't you agree that it would be optimal to… just have one unified codebase which can be used for everything and not two repositories that basically do the exact same but every feature has to be ported between those two?

I've looked into what you mean, and it seems like Docker is used to build the project, which is… kind of weird, considering the GitHub CI literally is a Docker container in which you access the shell, so it runs Docker within Docker (and the same would be achievable without a custom docker command).
But nevertheless, this is just used to build the project on a standardised system (basically a new Linux machine) so that building it will always be the same and not dependent on some system settings, and doesn't change anything about the source code or complicate it.