This builds on top of #1049, provides a fix for #1193, and adds further parameterization for users who want to tune this to their use cases.

The PR does the following

• Expose a compile-time parameter SENTRY_HANDLER_STACK_SIZE that sets the required stack size for the handler (for Linux/macOS using inproc and Windows using any backend, it defaults to 64KiB, which is also the current default).
• Expose a compile-time parameter SENTRY_THREAD_STACK_GUARANTEE_FACTOR which is the factor that the stack reserve of a given thread must at least be larger than the specified SENTRY_HANDLER_STACK_SIZE to ask for a guarantee (only Windows, defaults to 10x).
• Expose a compile-time option SENTRY_THREAD_STACK_GUARANTEE_AUTO_INIT that toggles between turning on and off auto-initialization of the thread stack guarantee for each thread after the sentry library has been loaded (if building as a dynamic library). This option only initializes the thread that calls sentry_init() when doing a static build (only Windows, defaults to On).
• Expose a compile-time option SENTRY_THREAD_STACK_GUARANTEE_VERBOSE_LOG that toggles between turning on and off INFO level logging of successful setting of thread stack guarantees (only Windows, defaults to Off).
• Provide a public interface (sentry_set_thread_stack_guarantee()) to allow users to set the stack guarantee for each thread manually if the auto-initialization doesn't behave as the use case requires it
• Adapt the auto-initialization to be much more defensive about which threads it attempts to request a stack guarantee for so we don't eat into the stack budget of threads with tiny reserves. The reserve and above meta-parameters play into the decision, which essentially boils down to this:
  if a thread doesn't have at least SENTRY_HANDLER_STACK_SIZE x SENTRY_THREAD_STACK_GUARANTEE_FACTOR of stack reserve, we won't request a guarantee from that thread.

Reasoning

• Most threads in users' processes will have enough stack reserve (1MiB) for our default guarantee (64KiB), so there is no reason to disable auto-initialization because most users will never be confronted with any issue
• However, no auto initialization should itself lead to a stack overflow, and thus, it makes sense to introduce a boundary at which guarantees will no longer be attempted
• The trade-off here is that users who have threads in their process that do not fit that boundary will have some threads without a handler guarantee (i.e. if these overflow, they will crash the application, but the crash won't be reported)
• This might sound like a bad trade-off; however, most of these threads will be outside the control of our users, and as such, any reports will be non-actionable.
• Further, we now expose parameters for the tiny group of users that control threads with limited stacks or with enough insight into third-party-controlled threads so that reports can be actionable if they are overflowing:
  • they can disable auto-initialization entirely and define guarantees for each thread as they see fit
  • they can change the handler stack size according to their usage of hooks (with or without auto-init)
  • they can change the thread stack guarantee factor so that threads with limited stacks will still be automatically initialized with a guarantee they have tested
• We keep the current default guarantee of 64KiB to avoid breaking the current handler assumptions in the field (particularly concerning hooks being called from the handler).