Allow manual generation of scaffolding and bindings from IDL file

[rfk]

The way uniffi is currently set up, optimizes for a very specific use-case: you're building a crate and you're going to publish it as a rust component, so you want uniffi integrated at the top level of your build process (cargo build produces the .so, cargo run -- generate produces the foreign-language bindings, etc).

From some thoughtful feedback from @tarikeshaq over in https://github.com/rfk/uniffi-rs/issues/24#issuecomment-661608571, it's clear that the first set of potential real-life consumers won't be shaped like that. They're more likely to want to tentatively integrate uniffi into the build process of an existing project, and it's not obvious how to do that based on what we have right now.

A strawfox proposal, broadly inspired by how we use protobufs in app-services:

• Invest in making a uniffi-bindgen tool that can be used in a standalone fashion, for integration with other build setups. We actually already have the beginnings of this, but it's hidden away in implementation details.
• Have a command like uniffi-bindgen scaffolding path/to/api.idl that can read an IDL file and spit out the rust code that flattens it into a C-style FFI. Rather than writing a bunch of pub extern "C" functions by hand, consumers could use this tool to generate them automatically from the IDL file and then include!() them into their rust code (or perhaps import them as a sub-module?).
• Have a command like uniffi-bindgen generate --language=<language> path/to/api.idl that can read an IDL file and spit out the appropriate foreign-language bindings to consume the C-style FFI from above. Rather than writing Kotlin, Swift etc code by hand, consumers could use this tool to generate it automatically from the IDL file, and then incorporate the generated files into their package build.

That's going to feel a bit clunky as a dev experience, in much the same way that working with protobuf files feels a bit clunky for us in app-services (like the CI job whose only purpose is to check that you didn't forget to generate the bindings). But from recent conversations, I think it could set us up to deliver early value quicker, without having to solve a bunch of more general tooling challenges up-front.

Most of the codegen pieces for this already exist, but need to be exposed for easy use in this new way from the command-line.

Thoughts? /cc @eoger @jhugman @linacambridge @tarikeshaq

┆Issue is synchronized with this Jira Task

[tarikeshaq]

I think this would be helpful! I also imagine we'd have a way of setting/detecting the native library that the generated code would load as a part of this effort.

Seems like that this would effectively take care of the human aspect of the writing the FFI, but still allows the human to be involved in putting it where they want it to be, I like it!

[rfk]

Some implementation notes:

• There's a bunch of code for running the command-line tool here in the top-level module. It should probably move into a sub-module! But right now, that's where to find it.
• This code doesn't currently know how to parse an IDL file, it instead knows how to read a serialized IDL from the compiled dylib (ref this line.) We probably need to teach it to look at the extension of the provided file, and call get_component_interface_from_cdylib when given a .so or use ComponentInterface::from_str like here when given a .idl.
• Other than that, I think this comes down to massaging the use of clap to produce the desired command-line interface.