Split SDK into feature-based modules

[armcknight]

Description

Customers should be able to selectively integrate separate SDK modules depending on the features they'd like to use. This would optimize the SDK footprint in each app, as instead of still shipping binary for unused features, they wouldn't be present at all.

This would be things like UIKit-specific features, or private API defined in ObjC that we want to be able to access in Swift without exposing to customers, which is where all the @_implementationOnly import and module.modulemap hacks are coming from.

This has other knock on benefits, like improved build times and enforcing cleaner APIs.

See for instance the customer request at #3181 (comment)

[bruno-garcia]

How does this affect installation steps and other SDKs that depend on the cocoa SDK?

[armcknight]

We can keep the current package as one that includes everything, and then have subpackages like sentry-core (which would do error/crash reporting), sentry-performance and sentry-UIKit, among other things, that could all be automatically included in the top-level Sentry package. So it shouldn't break anybody.

[bruno-garcia]

That makes sense. We did that on Android.
sentry-android is a meta-package that includes sentry-android-core (actualy has the Android specific core), sentry-android-ndk (native stuff) and sentry-java the core Java-only which is used also by backend Java/Kotlin/JVM.

So users who don't want the additional 1MB or whatever NDK support, could go straight to sentry-android-core but that's rare tbqh. We did need to have two packages for Android and Java (reusable) which is the reason we ended up with this design. All while allowing a simple installation method: Add sentry-android.

[armcknight]

It's soundung more like this is going to be needed for the long term health of the package. We more recently looked at SDK size, and splitting it up can really reduce the footprint for the average customer who may not want every single feature we offer. It would also help with the ongoing challenges around a UIKitless offering.