Consider Increasing Thread Limit in CrashReport

[GLinnik21]

Currently, the KSMachineContext struct in CrashReport has a fixed limit of 100 threads. This limitation may be insufficient for some applications. Since dynamically sizing this array isn't feasible due to its use in UNIX signal handling and mach-Exception, we need to consider whether increasing this limit is necessary.

KSCrash/Sources/KSCrashRecordingCore/include/KSMachineContext_Apple.h

Lines 44 to 53 in 4f00ac9

	typedef struct KSMachineContext {
	thread_t thisThread;
	thread_t allThreads[100];
	int threadCount;
	bool isCrashedContext;
	bool isCurrentThread;
	bool isStackOverflow;
	bool isSignalContext;
	STRUCT_MCONTEXT_L machineContext;
	} KSMachineContext;

• Necessity: Is the current 100-thread limit adequate for most applications, or are there significant use cases where this limit is exceeded?
• Increase Limit: If an increase is necessary, what should the new limit be? Options could include doubling the limit to 200 or selecting another appropriate number.

Would increasing the thread limit be beneficial, and if so, to what extent?

[DmT021]

If we can't afford a really big array to guarantee all the threads will be captured, then we should at least guarantee that the crashed thread is in the report.