MAINT, ENH: Try to speed up the `meson` backend

At the moment, since the switch to meson as the default, all the compile tests had to be marked slow. At first, it was assumed that the fixture based tests were at fault (https://github.com/numpy/numpy/pull/25252). However, on further investigation, the problem is that that the meson is quite a bit slower in general:

❯ hyperfine "f2py --verbose -c _bufrlib.pyf -m _bufrlib -L$PWD -lbvers --backend distutils" "f2py --verbose -c _bufrlib.pyf -m _bufrlib -L$PWD -lbvers --backend meson"
Benchmark 1: f2py --verbose -c _bufrlib.pyf -m _bufrlib -L/blah/playground/numpy_bugs/gh-25266 -lbvers --backend distutils
  Time (mean ± σ):     380.0 ms ± 179.0 ms    [User: 531.0 ms, System: 941.1 ms]
  Range (min … max):   219.0 ms … 656.2 ms    10 runs
 
Benchmark 2: f2py --verbose -c _bufrlib.pyf -m _bufrlib -L/blah/playground/numpy_bugs/gh-25266 -lbvers --backend meson
  Time (mean ± σ):      1.512 s ±  0.042 s    [User: 1.964 s, System: 2.480 s]
  Range (min … max):    1.465 s …  1.588 s    10 runs
 
Summary
  f2py --verbose -c _bufrlib.pyf -m _bufrlib -L/blah/playground/numpy_bugs/gh-25266 -lbvers --backend distutils ran
    3.98 ± 1.88 times faster than f2py --verbose -c _bufrlib.pyf -m _bufrlib -L/blah/playground/numpy_bugs/gh-25266 -lbvers --backend meson
hyperfine    25.10s user 34.36s system 309% cpu 19.216 total

This would be very nice to fix, but it is also kind of low prio right now (in light of the meson backend still sort of being brought up to speed / tests are running on CI, just maybe not as often as they could).

Start with the f2py commands and hyperfine comparison in the issue, then trace how the meson and distutils backends are selected and invoked. Reproduce the benchmark and identify the source of the meson slowdown; done means the meson backend is measurably faster without regressing its compile tests.