Move Swift publishing workflow to main repo

[cnixbtc]

Swift Publishing Workflow Consolidation

This PR relocates the Swift publishing workflow from the breez/breez-sdk-swift repository to the main repository. This change simplifies the publishing process by integrating it with the main repo's CI workflow.

📖 Overview

Previously, the Swift publishing workflow required separate triggers, unlike other platforms managed centrally in the main repo via the publish-all-platforms workflow. This PR enhances the Swift package publishing by:

• Streamlining the publishing process by integrating the Swift package into the main repo's CI workflow.
• Improving build runtime and reliability by reusing the already built binary SDK and language bindings from the main repo's workflows.

One interesting point: Because our Flutter and React Native packages rely on the Swift package at runtime, the PR includes logic to ensure that the Flutter and React Native packages are only published if the Swift package is successfully published too, preventing issues with runtime dependencies. If the Swift package is not set to be published, then the Flutter and React Native packages are published nonetheless allowing us to release updates to those packages that depend on an already published Swift package. Special thanks to @JssDWt for the solution adapted from this PR.

❓ Outstanding Questions

Before merging this PR, we need to address two key points. The first is straightforward, while the second requires some feedback.

1. Setting CocoaPods Token
   We need to set secrets.COCOAPODS_TRUNK_TOKEN in the main repo to publish to the CocoaPods trunk. This token is currently only set in the breez-sdk-swift repo (I believe we're using @roeierez's token there). The simplest solution is to just move the token from the Swift repo to the main repo.

2. Publishing breez_sdkFFI.xcframework
   The Swift package and CocoaPods require a download link to the breez_sdkFFI.xcframework binary artifact. Currently, we create a GitHub release in the breez-sdk-swift repo and attach the XCFramework as a binary artifact. Moving the workflow to the main repo presents a few challenges for maintaining this setup. I believe options 1 and 3 are the most straightforward, with option 2 being a viable alternative that may need some experimentation.

   • Option 1: Use a GitHub Personal Access Token to replicate the current setup. This would involve creating a release in the breez-sdk-swift repo from the CI workflow in the main repo. While simple, this requires using user-bound tokens with broad permissions, which isn't ideal.
   • Option 2: Use a GitHub app to provide short-lived tokens for the workflow. This option offers better security with non-user-bound tokens but requires more setup.
   • Option 3: Create the release in the main breez-sdk-greenlight repo instead of the breez-sdk-swift repo and attach the artifact there. This option is easy to set up and doesn't require special tokens, but it requires releases to be created on the main repo whenever we want to update or publish the Swift package. Not ideal, imo.
   • Option 4: Find an alternative hosting solution outside of GitHub for the artifact, accessible to our users.

✋ Feedback Request

I'd appreciate your thoughts on these options, particularly regarding the second point. Looking forward to your feedback. 🙏