docs: Add KSCrash migration strategy document

[NinjaLikesCheez]

📜 Description

Adds a develop-doc with the two potential migration strategies for KSCrash along with a recommendation of which approach to take.

💡 Motivation and Context

Early alignment on the strategy will allow us to start landing code changes incrementally sooner rather than later

📝 Checklist

You have to check all boxes before merging:

• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.
• If I added a new public API, I also added it to the SentryObjC wrapper.

#skip-changelog

Closes #8095

[philipphofmann]

Thanks for putting this together @NinjaLikesCheez.

Very important points that we need to address somewhere. Maybe they should be part of this document. If they're out of scope, please let me know:

1. Version update strategy — do we always point to the latest kscrash, or pin to a version and bump deliberately?
2. Should we have our own kscrash fork, or do we directly integrate kscrash? The benefit of our own fork would be that we won't be blocked by incidents and hotfixes. The key would be, obviously, that this fork, by default, should always be the same as KSCrash.

[supervacuus]

The migration work will certainly teach us humility, but

• Should we have our own kscrash fork, or do we directly integrate kscrash? The benefit of our own fork would be that we won't be blocked by incidents and hotfixes. The key would be, obviously, that this fork, by default, should always be the same as KSCrash.

We will start from a fork and try to upstream changes as much as possible, or create adapters on the sentry-cocoa side (even those might require upstream changes). Ideally, we can switch to the vanilla upstream at some point. But that is not a goal for the v10 release. It could also be the case that the fork will exist ad infinitum.

• Version update strategy — do we always point to the latest kscrash, or pin to a version and bump deliberately?

This depends on the above. I expect the fork to exist for a while, meaning we bump regularly, but whenever it makes sense. Even when a fork is no longer necessary, I think it is reasonable to pin, given how core behavioral changes are to the SDK (and also regarding the rather liberal versioning upstream).

[philipphofmann]

We will start from a fork and try to upstream changes as much as possible, or create adapters on the sentry-cocoa side (even those might require upstream changes). Ideally, we can switch to the vanilla upstream at some point. But that is not a goal for the v10 release. It could also be the case that the fork will exist ad infinitum.

I would really try to do vanilla as much as possible. If not, I see the risk that the fork deviates, and we put logic into the fork that should actually be in the Cocoa SDK. During the migration phase, which will be experimental, we don't need to worry about KSCrash's stability issues.

[NinjaLikesCheez]

I have opened a first go at the implementation mentioned in this document here: #8154

I would like to (of course) reach an agreement here, summerize this document to a decision (mentioned here: #8094 (comment)), remove the document in favour of the decision, and only then merge in this & #8154