Describe the bug

While hacking on #890, I decided to try and attach a fentry prog to all of my machine's symbols. Many of them fail with: attach Tracing/TraceFEntry: find target for fentry update_persistent_clock64 in vmlinux: type update_persistent_clock64: multiple candidates for *btf.Func

[1096] STRUCT 'timespec64' size=16 vlen=2
        'tv_sec' type_id=1095 bits_offset=0
        'tv_nsec' type_id=90 bits_offset=64
..
[28302] FUNC_PROTO '(anon)' ret_type_id=69 vlen=1
        'now64' type_id=1096
[28303] FUNC 'update_persistent_clock64' type_id=28302 linkage=static
..
[62944] FUNC_PROTO '(anon)' ret_type_id=69 vlen=1
        'now' type_id=1096
[62945] FUNC 'update_persistent_clock64' type_id=62944 linkage=static

update_persistent_clock64 is a weak vmlinux symbol that has an arch-specific implementation:
https://elixir.bootlin.com/linux/v6.1.1/source/kernel/time/ntp.c#L568
https://elixir.bootlin.com/linux/v6.1.1/source/arch/x86/kernel/rtc.c#L103

The argument in the weak symbol is named now64, the arch-specific one is called now.

Expected behavior

The library should either go with the first candidate, or additionally verify binary compatibility between all candidates' function signatures.

Or, we might be stuck between a rock and a hard place if the kernel expects the function's specific BTF id to be given. Perhaps we may need to try loading a prog pointing at each candidate until one is accepted.

Looks similar to #723 and #466.