Improve error handling in Objective-C and Swift bindings

[danpalmer]

This is a breaking change to the Objective-C and Swift bindings.

Why? – Because NSException which is currently used, is designed for unrecoverable runtime exceptions, not control flow. In Objective-C this is awkward to handle, and in Swift it's impossible to catch.

This change switches from throwing NSExceptions to returning NSErrors, in the style recommended for handling cross-language errors in the Apple documentation: https://developer.apple.com/documentation/swift/handling-cocoa-errors-in-swift. This is worth a breaking change in order to accurately represent the possibilities of errors in the API contracts in both languages.

The Objective-C APIs include an (NSError**)error argument, allowing callsites to pass an empty error pointer to be populated for error handling. This is a very common pattern in Objective-C APIs.

NSError *error = nil;
[index add:foo error:&error];
if (error != nil) {
    // handle error
}

In Swift, this is translated to a throwing error in the normal Swift way:

try {
    index.add(foo)
} catch {
    println("\(error)")
}

Additionally, the error enum is bridged to Swift so that errors can be disambiguated.

Fixes: #554

[ashvardanian]

Is there no way to highlight those functions as noexcept in C++ terms? That why they probably still be accessed as computed properties of the class instance, right?

[danpalmer]

I don't know. If you think the implementation of these will never throw, and don't want to reserve the ability to throw in the API then I can drop these though.