ruby: add DTV-based TLS access for ruby_current_ec

[dalehamel]

superceded by open-telemetry#1226

[dalehamel]

Coredump Test Plan

This PR needs a coredump test for a dynamically-linked Ruby on musl (Alpine Linux) to exercise the DTV-based ruby_current_ec lookup via dtv_read().

Test: ruby-3.4.x-dtv-loop (amd64 + arm64)

musl is the target because it uses DTV-based TLS (no TLSDESC), which is exactly the path this PR adds.

Setup (Alpine container):

docker run -it --privileged alpine:3.22 sh
apk add ruby gdb
echo 0x3f > /proc/self/coredump_filter

Verify musl uses DTPMOD64 (not TLSDESC):

readelf -r /usr/lib/libruby.so | grep DTPMOD
# Should show R_X86_64_DTPMOD64 or R_AARCH64_TLS_DTPMOD64
readelf -r /usr/lib/libruby.so | grep TLSDESC
# Should be EMPTY — musl doesn't use TLSDESC

Capture:

ruby /path/to/loop.rb &
PID=$!
sleep 2
./coredump new -pid $PID -name ruby-3.4.x-dtv-loop

What this exercises

• VisitRelocations() with DTPMOD64 filter finds the TLS module ID offset in libruby.so
• UpdateLibcInfo() receives DTVInfo extracted from musl's __tls_get_addr (via PR Extract DTV info from __tls_get_addr, add to LibcInfo open-telemetry/opentelemetry-ebpf-profiler#929's libc introspection)
• dtv_read() shared eBPF helper traverses: tsd_base → DTV pointer (via DTVInfo.offset + optional indirection) → DTV[module_id * multiplier] → TLS block → ruby_current_ec
• Expected frames should be identical in shape to existing ruby-3.4.x-loop tests

Important notes

• Coredump filter must be 0x3f to capture anonymous pages containing TLS/DTV data
• Both ld-musl-*.so and libruby.so must be included as modules in the coredump
• musl DTV parameters: Multiplier=8, Indirect=1 (vs glibc Multiplier=16, Indirect=0 on x86)

Files to add

• tools/coredump/testdata/amd64/ruby-3.4.x-dtv-loop.json
• tools/coredump/testdata/arm64/ruby-3.4.x-dtv-loop.json