Fix qmlimportscanner lookup

[meator]

See the added comment for explanation.

I could still default to which("qmlimportscanner") if the first two methods fail, what do you think?

[TheAssassin]

Thanks. How about keeping the original variant as a fallback?

[meator]

Do you think that there exists an environment that is

1. reasonably valid and worthwile to support and
2. does not have qmlimportscanner in QT_INSTALL_LIBEXECS nor QT_INSTALL_BINS, but does have it in PATH?

The only thing I can think of is the king of strange and program breaking environments, Nix. Nix's qmake lists

QT_INSTALL_LIBEXECS:/nix/store/r7wdw4nkkjii690wwnzkgj68cg4shh2v-qtbase-6.10.0/libexec
QT_INSTALL_BINS:/nix/store/r7wdw4nkkjii690wwnzkgj68cg4shh2v-qtbase-6.10.0/bin

on my computer but qmlimportscanner is in

/nix/store/rz0lc8irp5knfzwakm86p3ifkflr1w1i-qtdeclarative-6.10.0/libexec/qmlimportscanner

I wonder what even is the correct way to deal with this. pkg-config perhaps.

Looking up Qt executables is a pretty difficult task. If linuxdeploy-plugin-qt would like to make its system more robust, it could look for inspiration into for example Meson's logic (it isn't very readable if you don't know Meson internals, but it is still fairly straight forward Python).

Because I was able to come up with a scenario where PATH could be useful (user could add /nix/store/rz0lc8irp5knfzwakm86p3ifkflr1w1i-qtdeclarative-6.10.0/libexec/ to path to make linuxdeploy-plugin-qt) work, I'll implement it.

[TheAssassin]

Honestly, I don't know for sure. I was thinking that it couldn't hurt. But not a strong opinion.

[TheAssassin]

Thanks!