Don't hardcode Swift library names when running examples

[linabutler]

The way we run Swift examples now is hecka janky.

If you're using a generated library in an Xcode project, you only need the bridging header (am I using the right terminology for this? It's an "umbrella header" for the module map, but I think "bridging" means something very specific, and suspect this isn't that) and the .swift source file for the component—it'll take care of the rest. But, we need to do some clever things to run the example manually.

First, we compile our component.swiftmodule and libcomponent.dylib with swiftc, and link that with the Rust FFI library (libuniffi_component.dylib). If we don't link with the FFI library, it'll complain it can't find any of the C FFI symbols when it goes to compile the Swift module. We also have to pass it a module map, which has the path to the "bridging header" declaring the FFI symbols. The libcomponent.dylib is the weird part—why do we need that? Apparently, component.swiftmodule module isn't enough; without libcomponent.dylib, running import component will work, but calling any of its functions will fail with an error that it can't find the Swift symbol.

Then, when we want to run an example script that imports the component, we call swift (not swiftc), and link the example script with the component.dylib we emitted in step 1. We don't have to link the script with the FFI library, but we do have to pass the same module map again.

SPM does this automagically under the hood. The way I figured out these incantations was doing swift build -v and swift run -v, looking at the commands, and whittling down the arguments until it worked 😆

For us, though, we'll need a better way that doesn't rely on run_swift_script hardcoding library names and module map paths. @rfk mentioned in https://github.com/rfk/uniffi-rs/pull/6#discussion_r446863815 that the component name gets passed down here, which we'll need as the base for the different library and module map paths.

[rfk]

I had a little bit of a go at this as part of https://github.com/rfk/uniffi-rs/pull/18; I don't think what it's doing there is good but it's at least an improvement over hard-coding library names 😆.

[linabutler]

Fixed by #18!