Send cpu_type and cpu_subtype

[philipphofmann]

Description

A customer reported that retrieving the mach_header for the main binary can lead to app hangs, because dyld_get_image_header takes some locks see also kstenerud/KSCrash#431

sentry-cocoa/Sources/SentryCrash/Recording/Monitors/SentryCrashMonitor_System.m

Line 502 in fccc4e5

const struct mach_header *header = _dyld_get_image_header(0);

We use the mach_header for storing the binaryCPUType and binaryCPUSubType here

sentry-cocoa/Sources/SentryCrash/Recording/Monitors/SentryCrashMonitor_System.m

Lines 562 to 563 in fccc4e5

	g_systemData.binaryCPUType = header->cputype;
	g_systemData.binaryCPUSubType = header->cpusubtype;

We removed this with #6181 to prevent the app launch hang.

We should retrieve binaryCPUType and binaryCPUSubType on a BG thread and send this info alongside with the cpuType and cpuSubType, which we still store with crash reports but don't send to Sentry.

According to Claude

_dyld_get_image_header(0)->cputype
Returns the CPU type the binary was compiled for
Shows the architecture of the currently executing slice

sentrycrashsysctl_int32ForName("hw.cputype")
Returns the actual hardware CPU type
Shows what the physical processor is

// x86_64 app running on Apple Silicon via Rosetta 2
_dyld_get_image_header(0)->cputype           // CPU_TYPE_X86_64 
sentrycrashsysctl_int32ForName("hw.cputype") // CPU_TYPE_ARM64

// x86_64 iOS Simulator on Apple Silicon Mac
_dyld_get_image_header(0)->cputype           // CPU_TYPE_X86_64
sentrycrashsysctl_int32ForName("hw.cputype") // CPU_TYPE_ARM64

[linear]

COCOA-662 SentryCrash retrieve binaryCPUType on a BG Thread

[kahest]

we want to send this information from SDK (vs. infer it on backend from dsym) because that way it can be used also for other event types like Logs. we accept that this info might be missing depending on timing / race conditions