Fall back to defused fusermount3 when no setuid fusermount is found

[probonopd]

Fixes #150

Distributions running with NoNewPrivs replace the setuid fusermount3 with defused, which works without the setuid bit. The runtime skipped it because it only accepted setuid root fusermount binaries, so AppImages could not be mounted on such systems.

As suggested in #150 (comment), the PATH is first searched for setuid root fusermount binaries exactly as before. Only if none is found, a second pass looks for a non-setuid executable fusermount whose --version output identifies it as defused (fusermount3 version: <ver> (defused)), and uses that one. Other non-setuid fusermount binaries are still rejected, and FUSERMOUNT_PROG continues to override the search.

Tested the search functions in isolation with mock binaries: a plain non-setuid fusermount3 is skipped while a defused one is picked, a setuid root binary is preferred over defused even when it comes later in PATH, and non-executable entries are ignored. Not tested against a real defused installation.

[github-actions]

Build for testing:
artifacts i686
artifacts armhf
artifacts aarch64
artifacts x86_64
Use at your own risk.

[Skyb0rg007]

Distributions running with NoNewPrivs replace the setuid fusermount3 with defused,

Haha, I like @thkukuk's enthusiasm, but defused is a pre-alpha project; as far as I know no distribution is using it.

I wouldn't be surprised if another, different, non-setuid implementation of fusermount3 replaces defused, so I don't think that hard-coding the word (defused) makes sense. If you want to avoid selecting a non-setuid libfuse fusermount3, perhaps I can add a flag to defused's fusermount3 like --works-without-setuid: with libfuse, fusermount3 --works-without-setuid results in an unrecognized option error, while any setuid-less implementation could have that option return 0 (even future non-defused implementations).