Define optional additional system integration data/code

Some Linux workspaces/desktop systems have hooks for integration with the system besides application launcher system or process metadata like for windows of an application (already in current spec) or custom MIME type registration (#22).
Those hooks might not be only by data, but also by code. The latter as in-process as well as out-of-process extensions of the system.

The extensions are often closely coupled with a given version of an application software (due to used private API of internal application libraries or used private format of application specific data). So shipping the system integration extensions bundled with the actual application lowers the risk for users of running into incompatible combinations of application and integration extensions.

The additional extensions are often also desktop/workspace-specific, where either no cross-desktop/workspace freedesktop.org or other specification has been established, or where extensions are highly dependant on the unique capabilities of a desktop/workspace product line.

For an improved experience with AppImage-based applications it would be interesting to extend the AppImage specification to allow bundling also of solution-specific system integration extensions

### Some Challenges
#### Conflicting extensions with multiple (AppImage) versions of the same application
Possibly needs to be fixed by having a system where only one version of the AppImages can be the currently integrated one. Might also be a fix for the similar challenge with the custom MIME type registration (which icon version is used for files with that MIME type and which AppImage as handler).
Additionally the same application might also be installed in a version from non-AppImages (e.g. distribution packages), that needs to be handled as well somehow.

#### Who deploys solution-specific system extensions
To deploy an integration extension which is only usable with a given workspace/desktop system solution, needs special knowledge about that system.
One solution might be to have the AppImage itself do that, as the creator knows what specific extensions they added and for which systems. That though comes both with the disadvantage of code duplication as well as having to trust the code of the AppImage not to do bad things on deploying the system extensions. And then it completely will miss to do any clean-up if an AppImage is simply deleted.
Another solution is to extend the AppImage system integration tools (like appimaged) to learn about specific desktop/workspace solutions, to recognize any specific system integration extensions in an AppImage and to do the needed things for deployment/undeployment. This creates a dependency on the given AppImage system integration tool, which might not yet know about less popular workspace/desktop solutions. The abilities of the tool need to be communicated to the user in some way, so they have a chance to learn why some integration might not be happening for them on their system, while it happens for others, and ideally with pointer to a solution how to fix this for them.

#### Platform variants & version dependencies might be needed
Given that workspace/desktop specific integration extensions are done against a richer API which also tends to be less stable over time (stable vs. feature progress), the compile-once-run-everywhere approach of AppImage might not work that well with such extensions.
One approach might be to allow multiple variants of the same extension in one AppImage, tagged with version & platform dependencies. Needs more thinking.

### Examples for additional system hooks
* global search plugins (e.g. Plasma's KRunner)
* applets/gadgets/widgets for quick access to app managed data
* indexer plugins (e.g. for tracker or Plasma's Baloo) for custom MIME types
* file thumbnailing plugins for custom MIME types

### Example for an application with solution-specific system integration extensions
The IDE KDevelop provides the following extensions, where a "session" is an application instance profile with a set of projects loaded and specific settings:
* KRunner plugin to directly launch existing KDevelop sessions or get their window activated if already running
* Plasma widget to see a list of existing KDevelop sessions to quickly launch them or get their window activated