feat: Allow disabling of the crash-handler backend at runtime.

[supervacuus]

Fixes #705

• Instead of modifying any existing interfaces, I just added new API functions for sentry_options_t
• I am not sure if we need all the functions, but most of the options interface is symmetric (i.e. getters and setters) so I did the same, but still tried to hide the backend behind the API facade
• Added new option to example code to allow it to run in an integration-test

[Swatinem]

Looks good.

I originally had a different idea, to model this in a similar way as sentry_options_set_transport is used right now:

• Expose just an opaque sentry_backend_t (I think we even had this at some point in an older version)
• Have a sentry_options_set_backend(sentry_backend_t*)
• Because the type itself is opaque, and there is no way to construct it, the only thing you can do with the API right now is to pass in NULL to disable the backend.
• However this is forward compatible if we ever want to support custom backends.

What do you think about that proposal? It does not give you the possibility to inspect or re-enable the backend, but since sentry_options is only ever constructed once on application init, I don’t think having those APIs would provide too much value.

[supervacuus]

Your proposal is more generic and open-ended. If exposing the backend for user-defined implementations or just additional API could be a target in the future, then this is the better route. I agree that having an on/off switch for the backend isn't necessary, given it only mutates the options.

[Swatinem]

awesome!