RUM-16039: Upgrade Mach profiler sampler to sample CPU-time

[simaoseica-dd]

Important

This PR is intended to validate backend and frontend support for iOS CPU Time samples, and to assess whether the resulting data and visualization improve the current Wall Time only profiling experience.

What and why?

This PR adds optional CPU time sample collection to the iOS Mach profiler.

The current iOS profiler emits Wall Time samples, which are useful for understanding user-perceived latency, blocked threads, waits, and runloop stalls. However, Wall Time profiles can be noisy when many threads are idle or waiting, and they do not clearly isolate code that is actively consuming CPU.

CPU Time samples add a complementary view focused on active CPU work, such as expensive parsing, image processing, layout, etc. This should help validate whether CPU Time profiling provides better signal for compute hotspots while preserving the existing Wall Time behavior.

How?

The Mach sampler continues to run on the existing wall clock sampling interval. When CPU Time sampling is enabled, each sampled thread also reads its accumulated Mach thread CPU time from THREAD_BASIC_INFO using user_time + system_time.

The profiler stores the previous CPU Time value per thread and emits the delta between observations as a cpu-time sample value. Wall Time remains unchanged and is still emitted as wall-time.

CPU Time sampling is disabled by default and controlled through a feature flag. The Swift profiling feature writes the flag to profiling user defaults before the native profiler is created, allowing both app launch and continuous profiling paths to read the same configuration.

The resulting pprof can contain both wall-time and cpu-time sample types in the same profile, enabling backend and frontend validation without replacing the existing wall-time profiler.

Review checklist

• Feature or bugfix MUST have appropriate tests (unit, integration)
• Make sure each commit and the PR mention the Issue number or JIRA reference
• Add CHANGELOG entry for user facing changes
• Add Objective-C interface for public APIs - see our guidelines (internal)
• Run make api-surface when adding new APIs