Ideas to simplify the project going forward

The AppImage format has spawned a large open source community [ecosystem](https://github.com/AppImage/awesome-appimage/blob/main/README.md#awesome-appimage-) by now. At the same time, the AppImage project has become complex and unlike the original vision (probonopd/AppImageKit) where everything was meant to be small, simple, and in one repository has created a significant burden for the people maintaining it, including @TheAssassin and me.

So, going forward, I would like to:
* Strengthen the community around the AppImage format, and delegate more of the actual code to that community, instead of trying to do everything inside the AppImage project
* Reduce amount of code maintained inside the AppImage project to a bare minimum
* Reduce complexity of code and repositories inside the AppImage project, and specifically inside the AppImageKit repository, to a bare minimum
* Move everything else to community project(s) outside of https://github.com/AppImage/

My personal itches:
* Remove "complicated" (for me!) dependencies (like C++, CMake, and libappimage) for what remains inside the AppImage project, and specifically inside the AppImageKit repository, and have those things maintained by the community
* Switch to a static AppImage runtime that is more robust against future changes in Linux distributions (like [this](https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1965636) one)
* For the essential AppImage tools, deliver them as AppImages that bundle _everything_ or as static binaries, to make them more robust against future changes in Linux distributions
* Reduce the amout of stuff that I have to feel somehow respronsible for to essentially the AppImage spec and a very small set of tools
* Have to care roughly only about https://github.com/AppImage/AppImageSpec/, https://github.com/probonopd/static-tools/, possibly parts of https://github.com/probonopd/go-appimage/ in the AppImage project
* Ideally standardize on Golang where possible, statically link where not possible
* Prevent developers from producing AppImages/AppImages that don't "just work" on all still-supported Linux distributions and ideally even FreeBSD which I am pretty much exclusively using these days (e.g., by promoting AppImages that bundle _everything_)

Result of brainstorming with @TheAssassin earlier this year:

- [ ] 1. Version AppImageSpec; in a new version reduce/remove room for ambiguity
- [ ] 2. Write an AppDir spec. So far we just pointed at http://rox.sourceforge.net/desktop/AppDirs.html but factually started to use non-mandatory conventions like a top-level `desktop` file used by some of our `AppRun` implementations. It needs to be clarified whether things like that are MUST/SHOULD/CAN
- [ ] 3. In a new AppImage type, use a "resource system" that allows us to put e.g., update information and similar metadata into AppImages (and possibly other ELF compliant files) in a standardized way that is easy to parse e.g., by file managers (similar to [what Haiku does](https://medium.com/@probonopd/my-sixth-day-with-haiku-under-the-hood-of-resources-icons-and-packages-abec8d0e4ec6) but using a simpler format like `.ar`?)
- [ ] 4. Document how to create AppDirs/AppImages that bundle _everything_ and that decide at _runtime_ which version of things like GPU related libraries to use; document the tradeoffs between AppDirs/AppImages that bundle _everything_ and "traditional" AppDirs/AppImages
- [x] 5. Move non-essential repositories out of the AppImage project
- [ ] 6. Move everything except the runtime out of the AppImageKit repository
- [x] 7. Replace runtime by [static runtime](https://github.com/probonopd/static-tools/releases/tag/continuous)
- [ ] 8. Print a message if the AppImage was built on a newer system than the target system on which the AppImage is running (can be approximated e.g., by looking at glibc versions or something like that)
- [x] 9. Document and support `TARGET_APPIMAGE` [Done](https://github.com/AppImage/AppImageSpec/blob/f1631a2ab03703932ec31b6ec6cb1b119d6dcbdd/draft.md?plain=1#L255)
- [ ] 10. Document system requirements and assumptions, e.g., regarding `fusermount`

Update 11/2024:

- [ ] 11. Promote "AppImages that bundle _everything_"