Move "run app" logic to shared module.

[TheAssassin]

Currently, the "run" logic is available in the GUI application only, but it might be a good idea to move it out to a module shared between all applications. It might even make sense to move it to the Updater class, to allow other libraries to make use of its functionality.

Related to #31.

[probonopd]

Note that just executing a binary produces different results (at least in GNOME) compared to launching an application via its desktop file or via the menu:

• For applications that ship an icon but do not actively set the icon on their main window, the application icon will only show up in the dock if the application was launched via its desktop file or via the menu
• Also, the context menu items in the dock are only available if the application was launched via its desktop file or via the menu

I had written some code that emulates the "proper" way of launching something through its desktop file some time back, AppImage/AppImageKit#174 (comment). This is overkill for appimageupdatetool but we may want to consider this for AppImageUpdate.

Low priority though.

[TheAssassin]

Hm, the problem is that code links to glib, which I could successfully avoid as a dependency so far. First of all, the "run app" code has to be refactored out, however. If we add this behavior, it should probably not be part of libappimageupdate but the standalone applications.

[probonopd]

That is true. Ideally this would be invoked by runtime when running an AppImage. And indeed one would need to look deeper than this to understand how to re-create this without additional dependencies such as glib. So indeed probably out of scope here.

[TheAssassin]

@probonopd well we could always make a separate executable with that code.