Add performance counters/metrics for samplers - #811

What does this PR do?:
Adds an opt-in (-PenableSamplerPerf), zero-cost-when-disabled instrumentation layer (SamplerPerf/SAMPLER_PERF_PROBE) that measures elapsed wall time and sample count per sampler family (CPU, wallclock, alloc, liveness, nativemem, nativesocket). Each sampler's signal handler or hot path gets a probe call (ctimer_linux.cpp, itimer.cpp, perfEvents_linux.cpp, wallClock.cpp, j9/j9WallClock.cpp, objectSampler.cpp, livenessTracker.cpp, mallocTracer.cpp, nativeSocketSampler.cpp). Counters are exposed through the existing Counters/JFR/getDebugCounters() machinery (counters.h) and a summary table is printed at Profiler::stop() via SamplerPerf::report(). Also adds Agent_OnUnload in vmEntry.cpp so JVMTI-only (-agentpath) loads get the same shutdown path as JNI_OnUnload. New unit tests in samplerPerf_ut.cpp and a new doc page, doc/reference/SamplerPerfCounters.md, explain the caveats around reading the numbers (elapsed vs CPU time, cpu/wall subset relationships, cross-sampler nesting, bailed-out samples, and a bounded shutdown-time undercount race).

A sample output:

[java-profiler] sampler performance (elapsed wall time, not CPU time):
[java-profiler]   sampler            total (ms)        count     avg (ns)
[java-profiler]   cpu                  1273.333        59979        21229
[java-profiler]   note: cpu includes unwinding_ticks_async, and alloc includes liveness; do not sum them.

Motivation:
There was no way to measure each sampler's own per-sample overhead in isolation — existing counters track totals but not per-engine timing, making it hard to attribute latency regressions to a specific sampler.

Additional Notes:
Default builds are unaffected — without -PenableSamplerPerf the macro expands to ((void)0) and the counters occupy no enum slot or storage.

How to test the change?:
Build with -PenableSamplerPerf and run the new samplerPerf_ut.cpp gtest suite (wired into GtestTaskBuilder.kt/ConfigurationPresets.kt the same way as the existing faultInjection flag). For an end-to-end check, run any profiled JVM workload with the flag enabled and confirm the [java-profiler] sampler performance table prints at shutdown.

For Datadog employees:

• If this PR touches code that signs or publishes builds or packages, or handles
  credentials of any kind, I've requested a security review (run the dd:platform-security-review
  skill, or file a request via the PSEC review form).
  bewaire also runs automatically on every PR.
• This PR doesn't touch any of that.
• JIRA: PROF-16025

Unsure? Have a question? Request a review!