appimagetool: Use mksquash from path relative to main executable

[probonopd]

openSUSE is packaging appimagetool, and since appimagetool needs a patched version of mksquashfs (e.g., for supporting offsets) it is not desired to have the patched one on the normal $PATH where it would interfere with the normal mksquashfs of the distribution.

1. Do we need any mksquashfs patches other than the offset functionality, which since has been merged in the upstream mksquashfs? If offsets are the only reason for needing a private mksquashfs currently, then maybe openSUSE could just get the latest mksquashfs into the distribution and remove the need for the private one
2. If that is not possible and we still need a private one, we should have appimagetool look for a path relative to itself first, like /$(dirname($(cat /proc/self/exe))/../lib/appimagetool/mksquashfs and, if present, give it preference over the one on the regular $PATH

That would remove the need for the patch needed in openSUSE currently:
https://build.opensuse.org/package/view_file/OBS:AppImage/AppImageKit/own-mksquashfs.patch?expand=1

Reference:
electron-userland/electron-builder#1478 (comment)

cc @adrianschroeter

[TheAssassin]

1. I think an up to date upstream mksquashfs should suffice for creating AppImages. We could probably test that easily. But looking at the call, the only thing really special is the offset flag.

2. The question is more, how to ship that mksquashfs with appimagetool's package. Shouldn't we rather try to replace the call to the subprocess by calling library functions from squashfs-tools? Like with zsync2, that'd probably be cleaner, faster, and easier to work with and maintain. The question is how easy it is to use squashfs-tools for that purpose, but it should be by far easier than with zsync2, as the code doesn't have as many issues.

I'd like to hear what @adrianschroeter has to say, too.

[TheAssassin]

This has been implemented by #618.