Consider Merge into Desktop Client Repository

[i2h3]

This needs to be discussed with @camilasan, @mgallien, @nilsding, @Aiiaiiio and @Rello.

Pros

• Coherent Git history. Functionally dependent code changes are no longer split across multiple repositories. The full scope of a bug fix or feature implementation becomes visible.
• Less overhead. Less Git fiddling, less dependency reference management, less pull requests.
• Simplified developer experience. The NextcloudIntegration.xcodeproj will always directly reference the Swift package from the same directory, no need to always manually and temporarily reference it in the Xcode project for testing code changes in the dependency.
• Unlikely reuse. As the NextcloudIntegration.xcodeproj in the desktop client repository shows, this actually is not a fully standalone solution to implement a file provider extension for a Nextcloud. It could be, but some code has to be moved in either direction for that first. The likelihood of others adopting this package in their own projects is expected to be very low.

Cons

• The macOS file provider extension is a very specific module of the overall product. Kicking off all the desktop client checks on every change specific to this appears to be overkill and ineffective.

Other

• This being a standalone project likely is the result of starting as a personal project of @claucambra and to not impact the desktop client project too much. By now, it has become an essential feature.
• It could be carved out of the desktop repository again, the key is to keep the Swift package itself well isolated.

Tasks

• All work in progress branches must be integrated or discarded first. Especially the Swift 6 compatibility effort (Swift 6 Support #96 and related branch).
• GitHub Actions must be migrated, too. At best, with restrictions based on paths of changes.

[nilsding]

Fine by me, especially so if we're the only users of that component.

Kicking off all the desktop client checks on every change specific to this appears to be overkill and ineffective.

IIRC there's ways to only run specific workflows if certain paths were changed. Not entirely sure how this would work with the required checks though

[Aiiaiiio]

Seems like a good idea to me. Inside the desktop client repo we can still keep it mostly isolated so it's easy to lift if needed.