Question about TRACEPOINT benchmarking

Dear @bobrik, I took a closer look at the benchmark you created for different eBPF attachment types tracing the getpid system call. Thank you for the thorough work, it’s very interesting and well implemented!

I do have a question about the results related to the tracepoint case. In your evaluation of the tracepoint case, you used the `tp_btf` attachment type:
https://github.com/cloudflare/ebpf_exporter/blob/dabb53aa28f65d89869638da624bef27cecf1ae6/benchmark/probes/benchmark.bpf.h#L20

From what I understand (and confirmed via ebpf.docs.io and bpftool), `tp_btf` is a TRACING program type, not a TRACEPOINT program.

When I replace the macro to use a tracepoint attachment for getpid:

```c
#define TRACEPOINT_SEC() SEC("tracepoint/syscalls/sys_enter_getpid")
```
I observe different benchmark results, with tracepoints performing worse than fentry, differing from your results. Also, `tp_btf` fires on every syscall, not just `getpid`. Could you share your reasoning for using `tp_btf` instead of `tracepoint/syscalls/sys_enter_getpid` to specifically trace the getpid syscall? A `tp_btf`, raw tracepoint, shall be specified as such in the benchmark results instead of using the term tracepoint.

Start with benchmark/probes/benchmark.bpf.h at the linked attachment macro and compare the tp_btf setup with tracepoint/syscalls/sys_enter_getpid. Verify which events each attachment receives and how the benchmark labels them. Done means the attachment choice and benchmark terminology accurately reflect the measured program, with the differing results explained.

Written by the indexing model from the issue text.