Add support for checking for base dependencies

@Conan-Kudo suggested in https://twitter.com/Det_Conan_Kudo/status/1137997295490875393:

> When I made AppImages, I actually made the user experience better by adding support for checking for base dependencies I didn't want to ship using rpm itself. It was easy and didn't require root access. It helped inform the user whether or not the AppImage would work.
>
> I considered this equivalent to the base runtime checks a lot of Windows portable applications do to make sure they run on the version of Windows the user is trying to run them on. Doing so made the user experience much better and saner for everyone involved.
>
> But I shouldn't have to write those checks. Those should be built into how AppImages are made. That's a foundational property that the AppImage developers don't want to acknowledge is necessary for AppImages to be reasonably successful.

Sounds like a good idea. Are we talking about runtime or AppImage creation build time checks?

> Both. Build-time checks allow you to compose a list of base dependencies you need to check for. You obviously need to check them at runtime before executing the program contained in the AppImage in order to gracefully fail.

I like it very much. Do you still have your old code around and would you be willing to contribute it to the project?

> Not anymore, unfortunately. It's been a fair number of years, and I've lost the backup chain in between switching computers over the years that had it. It's not hard to write such checks with rpm in a distro-neutral way, though.
>
> At build time, you're more or less doing the equivalent of the rpm library dependency generator: https://github.com/rpm-software-management/rpm/blob/master/fileattrs/elf.attr … You'd filter out the runtime requires to check for based on what libraries you bundle, so you must check all ELF content in the AppImage to make the list.
>
> Because of the nature of RPM dependencies, even if you build your AppImage on CentOS 6 or CentOS 7, you'll be able to generate a list that works across all RPM distributions, since it's not based on package names, but the virtual names that are common to all.
> Then at run-time, you'd go through your list and do something like: `$ rpm --quiet --query --whatprovides "$DEP"`. If the return code is zero, then it is on the system. If it non-zero, then it isn't.

Do you see a way to do the same that does not involve querying the package manager, but checking the actual files on disk? Because not every distribution is using rpm...

> I sort of hand-waved that away and fell back to normal failure modes for AppImages on non-rpm based distros because of that. But often times the virtual names contain the filenames of libraries, so you *could* do a filename check if you know where libraries are installed...
>
> For example: `libc.so.6(GLIBC_2.29)(64bit)` contains `libc.so.6` and "(64bit)", which tells you that you should look for `libc.so .6` in `/usr/lib64` or equivalent directory. You can then run the `elfdeps` program to see if it supports it.
>
> So if you know you need a particular capability, you can check by running the following and checking if the output has a matching virtual name: `$ /usr/lib/rpm/elfdeps --provides /usr/lib64/libc.so.6`
>
> And voila, no `rpmdb` or rpm-managed system required, you're still able to do dependency checks, even on Debian or Arch systems, as long as `elfdeps` works. :)