Swift Linux Support

[danpalmer]

This PR is a second attempt at #563, but using the C bindings as the basis for Swift interop, rather than the C++ interface. This adds a layer of indirection, but drastically simplifies the interop types. Given that Swift/C++ interop is not yet capable of expressing the necessary types for USearch, this is a better option to split the Objective-C and Swift codebases, and ultimately, to support Swift on Linux.

What's changed

• A move to Swift errors (rather than NSExceptions). This was proposed separately in Feature: Swift exceptions #554, and I'm still in favour of that change to improve the Objective-C API, but to have an error mechanism in the Swift API we need some of those changes.
• API consistency, the clear method was missing, and it would be better to remain mostly API compatible.
• A re-written Swift layer using the new usearch_c module, backed by the C implementation.

What's not changing

Other than the necessary introduction of throwing functions (remember that the Swift interface currently cannot handle any errors at all, they explicitly crash the application), there are no API changes to the high-level "Sugar" interface. Additionally the tests do not change, other than to support thrown errors.

For most projects this upgrade should be a straightforward process of adding trys to calls and handling errors. Most production users probably already wrap the Swift interface in Objective-C to be able to catch exceptions, and can therefore simplify their code significantly.

Future improvements

These are purposefully left out of this implementation to keep it manageable and reviewable.

• Actor support, proper threading control. Currently USearch manages its own threading, there are limits to this though. We should try to figure out a Swift-appropriate way of bridging the gap. Possibly using a MainActor so that there is a guaranteed single instance, and internally manage the number of in-flight requests to the index up to the limit of the number of threads.
• Better error support. Currently USearch returns strings for errors. This makes sense for some languages, but in Swift we typically want an enum so that errors can be more informative and handled separately. A stable error code introduced on the C++ side could make this possible.
• Objective-C Tests. Previously this was tested via the Swift implementation. Now this needs its own tests, ideally in Objective-C.
• Improved Package structure. Minor, but the structure, dependencies, includes/excludes, etc, could probably be tidied up a bit. Out of scope here though I think.

[danpalmer]

Something that's not quite working here is that when depending on the library it complains:

Module 'usearch_c' requires feature 'cplusplus'

I'm not quite sure what causes this. Would appreciate someone with more knowledge of C++ interop chiming in here. One possibility is that the necessary settings to compile the C++ part aren't making their way through to the dependent build.