`find_program` produces an object with an inconsistent interface when `meson.override_find_program` overrides the specified program

[apache-hb]

Describe the bug the object produced by find_program('xxx') is of type ExecutableHolder rather than ExternalProgramHolder. Which produces incompatibilities when using the returned object. i.e. ExecutableHolder has no .version() method, and cannot be formatted by summary.

To Reproduce

# subprojects/example/meson.build
project('thing-provider', 'cpp')

# pretend theres a .wrap file that specifies program_names=thing 
exe = executable('thing', 'main.cpp')
meson.override_find_program('thing', thing)

# meson.build
project('example', 'cpp')

thing = find_program('thing')

# this line is fine if `thing` is found externally
# otherwise produces ERROR: Summary value in section 'Test Summary', key 'Program', must be string, integer, boolean, dependency, disabler, or external program
summary({ 'Program': thing }, section : 'Test Summary')

Expected behavior find_program always provides an object with a uniform interface

system parameters

• 1.4.0
• windows 11 build 22621
• ninja 1.11.1
• python 3.11.9

[dcbaker]

I have some half finished patches for this somewhere… let me find them

[apache-hb]

Somewhat related, quite a few functions that accept dep also cause errors when dependency uses a subproject as opposed to a system dependency. I've run into this with compiler.has_function and compiler.has_header

[dcbaker]

Those can probably error more gracefully, but if those are from a subproject they can’t be used for tests because they don’t yet exist