[3.15] gh-150723: Fix perf jitdump files on macOS (GH-150728) (#150832)

[3.15] gh-150723: Fix perf jitdump files on macOS (GH-150728) (#150832)

gh-150723: Fix perf jitdump files on macOS (GH-150728)

The perf jitdump format defines the thread id field of the JR_CODE_LOAD
record as a 32-bit value, but on macOS it was declared as a uint64_t
(since pthread_threadid_np() returns a uint64_t). Those extra 8 bytes
plus alignment padding shifted every following field, so parsers reading
the file by the spec misread code_size as the code address and failed to
resolve any Python frames.

Declare thread_id as uint32_t on all platforms and truncate the macOS
thread id when writing the record. The value is only informational.
Symbols are resolved by address, and not thread ids so truncation is
safe here.

* Use mach_absolute_time for macOS jitdump timestamps

On macOS the jitdump file is consumed by profilers such as samply, which
timestamp their samples using mach_absolute_time(). The jitdump events were
stamped with clock_gettime(CLOCK_MONOTONIC), a different clock domain that
keeps advancing while the system is asleep, so the JIT code mappings could be
off by days relative to the samples and no Python frame would resolve. Stamp
jitdump events with mach_absolute_time() on macOS so they share the sampler's
clock domain. Linux continues to use CLOCK_MONOTONIC to stay aligned with perf.

Exercise the -Xperf_jit (jitdump) backend through samply and assert that
Python frames resolve, exercising the binary jitdump path end to end.
Skipped when samply is not installed.
(cherry picked from commit 494f2e3c92cc1b7774cca16fca5c7d1ff18c0de2)

Co-authored-by: Nazım Can Altınova <canaltinova@gmail.com>