fix: Prevent daemonize mode from crashing upload process

[kamilogorek]

In macOS 10.13, changes to Objective-C runtime forbid calling ObjC code before and after forking the process. If we want to do that, and we need to, due to moving sentry-cli process to the background during XCode artifacts upload, we need to perform all those calls after we daemonize ourselves. This forces us to not spawn any processes, nor call any ObjC-compiled code (like cURL) before we actually get to that branch.

The thing that's detaching us is MayDetach::wrap via MayDetach::may_detach function.

If we call any cURL code or spawn any process before-hand, it will result in the background process crashing with:

objc[80549]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[80549]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.

This PR does the following:

• disable signal handling for processes spawned via XCode (prevent direct process spawning); we can afford that, as our upload process is a standalone Build Script, and not part of the larger mechanism, thus we never expect it to be interrupted.
• disable default built-in crash reporting (prevent process spawning in SDK transport constructors); this part was never used for years in the first place (see: 2b6bedb) and it was always meant to be used for us to track CLI issues. Original initialization code was still in place though, so it was executed despite lacking the necessary DSN (it initialized empty client).
• move API initialization inside the wrapped function (prevent calling internal curl code);

ref: https://www.wefearchange.org/2018/11/forkmacos.rst.html
ref: http://sealiesoftware.com/blog/archive/2017/6/5/Objective-C_and_fork_in_macOS_1013.html

[marandaneto]

@kamilogorek is it related to getsentry/sentry-react-native#1424 and the --force_foreground issue?

[kamilogorek]

Yes, that's exactly that.