Enable Strict Concurrency Checking

[pauljohanneskraft]

Enable Strict Concurrency Checking

♻️ Current situation & Problem

Fixes #103

⚙️ Release Notes

• Enables Strict Concurrency Checking to prepare for the upcoming Swift 6 changes

📚 Documentation

No documentation changes needed, since strict concurrency checking does not emit any warnings and therefore does not require any changes to the actual implementation.

✅ Testing

No additional tests needed, since the changes should only trigger more warnings by the compiler and otherwise not change anything.

📝 Code of Conduct & Contributing Guidelines

By submitting creating this pull request, you agree to follow our Code of Conduct and Contributing Guidelines:

• I agree to follow the Code of Conduct and Contributing Guidelines.

[pauljohanneskraft]

I opened this PR first to confirm that these are the intended changes or get feedback on whether you would like to have this set up a different way. If this is the intended way, I can then open PRs to all the other Spezi components.

[PSchmiedmayer]

@pauljohanneskraft Thank you for taking a look at this!!

Two things I am wondering and would love to get your and others input @StanfordSpezi/developers:

1. It seems like the changes do create some warnings that we would address before a PR is merged, e.g.: https://github.com/StanfordSpezi/Spezi/actions/runs/8943078512/job/24570618361?pr=104. Is there a way that we can enforce warnings as errors to ensure that all warnings are addressed before PRs are merged?
2. I think it would also make sense to enable strict concurrency checking in the Xcode project of the UI testing application to validate that we don't run into any warnings when using the types (which sometimes seems to be the case when using the APIs, e.g., missing Sendable conformance).

Would be great to get your thoughts on both ideas and how we might be able to do this here and in other PRs.

[pauljohanneskraft]

I totally agree with 2, I set the SWIFT_STRICT_CONCURRENCY setting in UITests.xcodeproj to complete for all targets in this commit.

Regarding 1, I have added an input parameter to the workflow here.

[PSchmiedmayer]

Thank you for the improvements @pauljohanneskraft! Thank you for resolving 2).

I would propose the merge strategy and testing detailed in StanfordSpezi/.github#50 to get this PR merged, address all the warnings to check that merge checks switch to green when they are resolved and then merge the PRs in the proposed order.

[PSchmiedmayer]

Closed after we have updated the CI and setup in #108