Chore: MOBILE-4162 - Upgrade Iterable SDKs & add Swift Package Manager support

[mabidakun]

MOBILE-4162

What does this PR do? 🧐

Upgrades the iterable_flutter plugin's native Iterable SDKs to the latest and adds Swift Package Manager (SPM) support, releasing v0.8.0.

Native SDK upgrades (to latest):

• iOS Iterable-iOS-SDK 6.6.4 → 6.7.3 (includes the iOS 18 push-delivery-sandbox fix)
• Android com.iterable:iterableapi 3.6.3 → 3.9.0
• No breaking-change exposure: the plugin's Dart/native surface uses only stable APIs, and the only upstream removals (embedded-message tracking) aren't used here.

Swift Package Manager support:

• Adds ios/iterable_flutter/Package.swift so the plugin can be consumed via SPM, alongside CocoaPods (Flutter falls back to CocoaPods when SPM is off).
• Restructures the iOS sources to the SPM layout as a Swift-only target — removes the redundant Objective-C forwarding shim and renames SwiftIterableFlutterPlugin → IterableFlutterPlugin (registration still bridges to +registerWithRegistrar:).

Example app modernisation (required for the example to build under Flutter 3.44):

• Android project migrated to Gradle 8.9 / AGP 8.7.3 / Kotlin 1.9.20 with the declarative plugins block (dropped dead jcenter()).
• Replaced the abandoned, Flutter-3.44-incompatible flutter_config with flutter_dotenv (pure-Dart .env loader).

⚠️ Prerequisite for SPM to function — repository rename required

Flutter derives the Swift package identity from the plugin's repository folder basename, which must match the Dart package name (iterable_flutter). This repo is named iterable-flutter (hyphen), so SPM integration fails an identity check (unable to override package ... identity mismatch) until the repo is renamed iterable-flutter → iterable_flutter. Proven by build tests across folder names.

CocoaPods is entirely unaffected, so the SDK upgrades are usable now regardless. Because v0.8.0 ships Package.swift, consumers should stay on CocoaPods until the rename, then adopt SPM.

Test Evidence

Scenario	Result
iOS example builds under CocoaPods (Iterable 6.7.3)	✅ Xcode build done; Podfile.lock → Iterable-iOS-SDK (6.7.3)
iOS example builds under SPM (from a correctly-named folder)	✅ Xcode build done; SwiftPM resolves swift-sdk 6.7.3
Android example APK builds (iterableapi 3.9.0)	✅ Built app-debug.apk; manifest-blame → iterableapi:3.9.0
Plugin Android unit tests (NotificationParserTest)	✅ 3/3 pass
Dart tests (flutter test)	✅ 13/13 pass

How should this be manually tested? 🤓

1. cd example && flutter pub get
2. iOS (CocoaPods): cd ios && pod install then cd .. && flutter build ios --simulator --no-codesign → builds; Podfile.lock shows Iterable-iOS-SDK (6.7.3).
3. Android: flutter build apk --debug → builds; gradle resolves com.iterable:iterableapi:3.9.0.
4. Dart: from the repo root, flutter test → 13/13 pass.
5. SPM (only after the repo is renamed to iterable_flutter): flutter config --enable-swift-package-manager then flutter build ios --simulator --no-codesign → SwiftPM resolves swift-sdk 6.7.3.

Any background context you want to provide? 🤗

• The upstream La Haus iterable_flutter is abandoned; SpringCare maintains this fork.
• The example modernisation was necessary because Flutter 3.44 rejects the example's legacy Android build (imperative plugin loader, AGP 7.0.0) and because flutter_config (latest, 2.0.2) still references Flutter's removed v1 Registrar, making it Android-incompatible.
• Follow-ups (separate tickets):
  1. Org admin renames the repo iterable-flutter → iterable_flutter (needed for SPM identity resolution).
  2. Update Cherubi's iterable_flutter git dependency to the new repo URL + ref: 0.8.0.
  3. Optionally enable Swift Package Manager app-wide in Cherubi.