Speed up gdk commands by 200ms

What does this merge request do and why?

This speeds up all gdk commands by around 200ms (on my M3 MacBook Pro) by moving the support/pg_bindir Ruby script into the current GDK process.

Starting a ruby script can take up to 60ms. And we currently run support/pg_bindir twice, once when we validate_yaml! and once when we populate GDK.config. We could also look into memoizing this value but it only takes around 20ms to compute using mise (asdf might be 11 longer?).

While this is a great DX improvement (up to 50% speedup of gdk config get executions!), the speedup is also relevant for programmatically accessing config options in Multiple Cells with one GDK (#1945 - closed).

How to set up and validate locally

1. Checkout main
2. Run time gdk config get rails_web.enabled
3. Note down the time it took
4. Checkout this branch
5. Run time gdk config get rails_web.enabled
6. Compare the time (expectation: about 420ms -> 220ms)

Benchmark

main

$ hyperfine --warmup 10  "gdk config get gdk.debug"
Benchmark 1: gdk config get gdk.debug
  Time (mean ± σ):     937.7 ms ± 157.5 ms    [User: 823.9 ms, System: 182.7 ms]
  Range (min … max):   782.3 ms … 1298.7 ms    10 runs

This branch

$ hyperfine --warmup 10 "gdk config get gdk.debug"
Benchmark 1: gdk config get gdk.debug
  Time (mean ± σ):     516.8 ms ±  13.7 ms    [User: 488.6 ms, System: 95.3 ms]
  Range (min … max):   495.5 ms … 535.0 ms    10 runs

Impacted categories

The following categories relate to this merge request:

• gdk-reliability - e.g. When a GDK action fails to complete.
• gdk-usability - e.g. Improvements or suggestions around how the GDK functions.
• gdk-performance - e.g. When a GDK action is slow or times out.

Merge request checklist

• This change is backward compatible. If not, please include steps to communicate to our users.
• Tests added for new functionality. If not, please raise an issue to follow-up.
• Documentation added/updated, if needed.
• Announcement added, if change is notable.
• gdk doctor test added, if needed.
• Add the ~highlight label if this MR should be included in the CHANGELOG.md.