feat: [SDK-4774] add Unity location opt-out plumbing

[fadi-george]

Description

One Line Summary

Adds the Unity SDK plumbing for flag-controlled no-location native dependency resolution.

Details

Motivation

Unity builds need the same native location opt-out pattern as .NET, Capacitor, and Cordova without mutating shared package files. This lets apps exclude the native location module from iOS and Android builds while keeping the public OneSignal.Location API available as a graceful no-op path.

Scope

• Adds ONESIGNAL_DISABLE_LOCATION support layered over the Editor setting, with the environment variable taking precedence for CLI and CI builds.
• Generates EDM4U dependency manifests per consuming Unity project under Assets/OneSignal/Editor instead of rewriting package Editor files.
• Updates iOS post-processing for the no-location native define, notification service extension dependency selection, and CocoaPods duplicate output handling.
• Updates Android/iOS missing location module behavior to log SDK-level errors and no-op safely.
• Updates CI/release workflows and the main demo generated dependency manifest locations.

Testing

Unit testing

Not added; this is Unity Editor build-pipeline and native dependency resolution behavior.

Manual testing

• Verified as part of the original SDK-4774 branch before splitting:
  • examples/demo/run-ios.sh --no-install generated umbrella iOS and Android manifests.
  • examples/demo-no-location/run-ios.sh --no-install generated granular iOS pods without OneSignalLocation.
  • xcodebuild for the no-location iOS simulator build completed with EXIT=0 and no OneSignalLocation.framework linked.
  • examples/demo-no-location/run-android.sh --no-install built an APK with granular Android dependencies.
  • ./run-all.sh --sdk=unity --platform=ios passed with 34 tests.

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
• I have reviewed this PR myself, ensuring it meets each checklist item

Made with Cursor