Updating AppImage logic to support desktopintegration again

[jonoomph]

Fixing a regression which did not use the official AppRun executable... and thus our openshot-qt.wrapper was never called, which is what enables desktopintegration. I know this must still have some issues, since I'm having to do some of my own bootstrapping (which I should need to do, in order for libopenshot to be found at runtime). But this seems to work on all the distros I've tested on so far.

The basic flow:
1 - AppImage is mounted and executes AppRun in the root of our image. This is the official version of AppRun executable, and is a binary file.
2 - AppRun searches our *.desktop file, and locates the openshot-qt-launch.wrapper line, and then searches for that file, and executes it. This file is the desktopintegration file packaged along with AppImage code (renamed as openshot-qt-launch). It prompts the user to create a launcher, and then finally, removes the .wrapper and calls openshot-qt-launch.
3 - openshot-qt-launch is a renamed version of installer/launch-linux.sh. This exports LD_LIBRARY_PATH and QT_PLUGIN_PATH to the current directory (i.e. the usr/bin folder in our AppImage), and then finally, executes usr/bin/openshot-qt, which is a binary created by cx_freeze (and is the official entry point to our source code). Without this script, libopenshot and Qt fail to be found inside the AppImage... which is strange and incorrect. But it's a simple work-around for now.

Finally, I also enabled auto-transform, which enables transform for any selected clip. To make it disappear, simple unselect all clips. I think it really improves visibility on transforming elements during video editing. It can be disabled in the Preferences.

[ferdnyc]

@jonoomph

The reason we were using our own AppRun binary was #3283 & #3305. (Well, #3242 / #3293, which they fixed).

I compiled it from the sources the official one was built from, though, with the only change being the addition of that environment variable.

If /home/ubuntu/apps/AppImageKit/AppRun file is still the same ancient one compiled back in 2014, then without that fix, the AppImages will likely go back to crashing on launch, on Debian 11.

But if it's been rebuilt (as part of the Bionic builder update?) to use a newer libssl.so, then that should be fine, the workaround wouldn't be needed anymore.

[ferdnyc]

(Actually, I don't think the AppRun itself was the problem, it was something bundled into the AppImage — possibly the cx_Freeze binary launcher, because the only way to get OPENSSL_CONF=/dev/null into the environment soon enough to prevent the crash was to build it into the AppRun binary itself.)

But if that old-incompatible-OpenSSL dependency has been upgraded, then like I said no longer a problem. We should check that this didn't re-break Debian 11 support in the AppImage, though.