Allow .version() to be called for overridden executables

[sp1ritCS]

Right now, the set of available methods depends on the type of object returned by find_program. Specifically it fails if you attempt to call version on it, if it was an Executable put there with meson.override_find_program.

This also makes it possible that .get_version() can be called on the output of _find_tool by the modules (which is kind of required for #14422 [not really, as the returned value should never be an executable; but the mypy can't know that]).

For now this only uses the version of the subproject that called override_find_program but an additional version kwarg for meson.override_find_program could be added if required (at least from the Executable side, not sure about ExternalProgram)

[bonzini]

For now this only uses the version of the subproject that called override_find_program

I think that's smart and qualifies this patch as more of a bugfix than a feature.

[eli-schwartz]

For now this only uses the version of the subproject that called override_find_program but an additional version kwarg for meson.override_find_program could be added if required (at least from the Executable side, not sure about ExternalProgram)

This is probably "usually correct", but while less common there are projects that have separate version numbers for a library and a program that are built together.

We can infer versions of a dependency from the project version but there is still a way to annotate them with an explicit version. There's not currently a way to do that for an executable though! (And of course we can't run it with the --version flag at setup time.)

[sp1ritCS]

This is probably "usually correct", but while less common there are projects that have separate version numbers for a library and a program that are built together.

I know, thats why I mentioned the possibility of having a version kwarg for meson.override_find_program (@jpakkane mentioned to me that there was already work on exactly that kwarg some time ago, but it seemingly fizzled out and I didn't find it).

Right now it is linked to subproject version regardless of this PR or not, as if you do find_program(..., version: '>= XXX') the version guard already checks only against the subproject version.

[jpakkane]

We can add functionality to specify a custom version later if need for it comes up.

Test failures are unrelated.