Update Podspec to the new project structure

[GLinnik21]

No description provided.

[GLinnik21]

This is a subspecs approach that mimics the SPM structure. The main problem with this is that only individual podspecs can be modules, so we don't get the modular separation of SPM. With subspecs, everything ends up being a KSCrash.framework module with all the headers flattened together. A custom module map might be the solution, or podspecs for each module like Firebase does.

[GLinnik21]

The issue with the .modulemap file arises when trying to define modules for both .a libraries and .framework libraries. Here’s how it usually looks:

module KSCrashCore {
    header "KSSystemCapabilities.h"
    header "NSError+SimpleConstructor.h"
    export *
}

module KSCrashFilters {
    header "KSCrashReportFilterAlert.h"
    header "KSCrashReportFilterAppleFmt.h"
    header "KSCrashReportFilterBasic.h"
    header "KSCrashReportFilterGZip.h"
    header "KSCrashReportFilterJSON.h"
    header "KSCrashReportFilterSets.h"
    header "KSCrashReportFilterStringify.h"
    export *
}

This setup works fine for .a libraries with use_modular_headers!. However, issues arise with .framework libraries as they require a framework declaration, leading to warnings like:

    - WARN  | [KSCrash/RecordingCore] xcodebuild:  /<user_path>/DerivedData/App-borbxcvqwzuqknepndaqdvyfloem/Build/Intermediates.noindex/Pods.build/Release-iphonesimulator/KSCrash.build/module.modulemap:44:12: warning: skipping 'KSDebug.h' because module declaration of 'KSCrashRecordingCore' lacks the 'framework' qualifier [-Wincomplete-framework-module-declaration]

Even if you specify modules with a framework tag, .a libraries typically work fine since CocoaPods automatically removes the framework specifier. However, this gets complicated with .frameworks, where things like "submodules" are necessary but restrictive due to the required folder structure and limitations in having multiple parallel framework modules. According to the official Clang documentation on module and submodule declarations, you can't just set up multiple parallel framework modules. If you use submodules, they require a specific folder structure which adds another layer of complexity.

So, we're left with these options:

1. Leave as is: Users will simply import KSCrash, and the module's contents will adjust based on the specified subspec. This approach leaves all "private" API modules exposed to the library users, which could be a downside if encapsulation is a concern.

2. Create separate podspecs for each module: This is the only straightforward method fully supported by CocoaPods for handling Clang/Swift modules. By defining separate podspecs, each module can be independently managed and integrated, although this approach increases maintenance overhead and complexity in project management.

[bamx23]

Why is this -fno-optimize-sibling-calls flag removed?

[GLinnik21]

I guess we can set it in CocoaPods, but in SPM it can only be set with .unsafeFlags, which is not allowed in "release" (specified by version), but is allowed in development (local package or specified by commit or branch).

[GLinnik21]

It's also unclear which functions this flag is for, so we can't know if it's needed in Recording or in RecordingCore.

[bamx23]

Well, you've added it here #379 :)
Looks like it's actually needed. But maybe we can take a solution from rollbar/rollbar-apple#335 (if I understand that fix correctly).

[bamx23]

All looks great! Let's just make sure that TCO is addressed later.