feat(rust): import stubs for native targets

[BjornTheProgrammer]

This PR adds the ability for the user to provide a macro to rust that then can generate native funciton stubs, as described in #1062.

There were a few explored different alternatives, and the reasoning for using a macro is provided in the original issue.

Alright, I've embarked on implementing this. I've thought of a couple of different solutions, but they all have their pitfalls.

Weak links would be ideal, but either require nigthly until rust-lang/rust#29603 is implemented, or for the end user to have a c compiler on their machine, which I've read in the github action code isn't ideal.

I then thought to just emit a trait that has every function that then can be defined, but this has limitations on using codegen to implement all of the native functions with a default implementation.

This left me with an admittedly more complex solution then I'd like of passing in a macro to bindgen that then can generate the implementations.

It is not great code, but I'll open up a draft PR. Please feel free to give me feedback on the approach that I'm taking, and whether there should be any changes.

There are still a few things I'd like to change, but as a proof of concept you can do something like the following to automatically create a trait for all native stubs.

pub use crate::wit::Context;

mod wit {
    macro_rules! native_trait_stubs {
        ($stub:ty, $module:literal, $import:literal,
         fn $name:ident($($p:ident: $t:ty,)*)) => {
            <$stub as crate::wit::NativeStub>::$name($($p,)*)
        };
        ($stub:ty, $module:literal, $import:literal,
         fn $name:ident($($p:ident: $t:ty,)*) -> $ret:ty) => {
            <$stub as crate::wit::NativeStub>::$name($($p,)*)
        };
        (@definitions $stub:ty,
         $($module:literal, $import:literal, fn $name:ident($($p:ident: $t:ty),*) $(-> $ret:ty)?;)*
        ) => {
            pub trait NativeStub {
                $(fn $name($($p: $t),*) $(-> $ret)? {
                    unreachable!()
                })*
            }
        };
    }

    wit_bindgen::generate!({
        skip: ["init-plugin"],
        path: "../../wit",
        world: "plugin",
        native_stub_macro: native_trait_stubs!(crate::MyContextStub)
    });

    use super::Component;
    export!(Component);
}

struct MyContextStub {}
impl wit::NativeStub for MyContextStub {
    fn drop(_p0: i32) {
        todo!()
    }

    fn wit_import1(_p0: i32, _p1: *mut u8) {
        todo!()
    }
}

I have a minimum testing repo that can be found here

[alexcrichton]

Thanks for the PR, and I'm trying to page this all back in and understand the motivations/intentions here. Correct me if I'm wrong, but the high level idea is to be able to satisfy, on non-wasm platforms, wit-bindgen-generated bindings with a native implementation. Is that correct?

If so, I'm second-guessing this a bit in the sense of why go through ABI-marshalling at all? For example if you're calling a WIT function it seems like it'd be best to just turn around and immediately call a native function rather than serializing to some ABI-based representation just to deserialize and call a host function. Does that make sense to fit in here at all? Or am I perhaps missing something? (I could very well be)

[BjornTheProgrammer]

This PR despite making the possible stubs very modular, suffers from a lot of issues, I'm going to close this in favor of another PR that I've been making. The idea is a bit different, and slightly more complex then just calling a host function, since that would require the host binary to be compiled with "-rdynamic" on linux, and it wouldn't even work on Windows and MacOS.