Build AppImages

[TheAssassin]

This PR adds a script that builds AppImages for decklink-debugger. This way, decklink-debugger can be run on virtually any Linux distro (given the DeckLink libraries are installed).

We could extend this PR to build AppImages on Travis CI for every commit automatically (continuous releases).

Another idea is to amend the build script to allow for easy bundling of the Blackmagic DeckLink drivers for private deployments.

[MaZderMind]

When this gets merges, doesn't it need a .travis.yml to call travis/build-appimage.s?

[TheAssassin]

@MaZderMind thinking about it, IIRC I didn't add one directly due to licensing issues. I'm pretty sure the BM libs may not be bundled, which wouldn't necessarily be a problem. The problem is how to get the Blackmagic SDK on the Travis build machines to be able to build the software and AppImages. I think there was a little chat about it, but we didn't come up with a solution. Ideas welcome.

[MaZderMind]

We could build the AppImage on our Jenkins which has the Decklink SDK and already compiles a Debian-Package. I don‘t know about publishing that, though.

[TheAssassin]

You told me that to use software, at least the blackmagic library packages must be installed anyway, as they provide a mandatory kernel module. So I guess we can safely assume that the blackmagic libs are installed anywhere the AppImage will be used (the SDK a.k.a. dev files are not needed in that scenario). That'd mean they could be excluded from the AppImage. The software would only be linked against the files, and then put in an AppImage. Wherever the AppImage is used, the system libs would be used then.

The question is whether the license of the blackmagic libraries allows for that, but I cannot imagine any scenario in which they could prohibit that. So I guess that'd be safe. But we could check their license. It'd be quite pointless if it'd prevent this, though.