Add accessor support

[bvisness]

Currently implemented for C, C++, and Rust. Other languages have todo!() in several switch statements. This is probably not even actually sufficient on its own but tests are being a real pain locally so I want to start running some things here.

We might need to propagate updates into wasm-component-ld and friends for all of them to run...

[bvisness]

Yeah, there's quite a lot of this:

        Error: failed to parse WebAssembly module
        
        Caused by:
            export name `[method][get]blob.position` is not a valid extern name
        `[get]blob` is not in kebab case (at offset 0x6e4)

I guess this means more wasm-tools version bumps are in order.

(fwiw, I determined that the case I was worried about on Zulip was not, in fact, a bug, so as of now I am not in fact aware of any bugs of mine in wasm-tools.)

[alexcrichton]

Most of the errors to me look like it's wasmtime not supporting getters/setters yet. I think that'd be fixable by updating Wasmtime to plumb the feature through to the CLI and then using the dev release here to run tests (and the test will probably need some sort of configuration to pass the right -W flag or something like that)

For building the theory for most targets is to emit a core wasm module and then use the tooling via dependencies to do what wasm-component-ld-would-have-done, precisely to handle this issue where new features are in development. C/Rust for example should both pass --skip-wit-component to the linker. It looks like C++ here might not be doing that, but that should in theory be a pretty small change to crates/test/src/cpp.rs

[alexcrichton]

generated code?

[bvisness]

Not quite...it's modeled after this file, and it implements the Blob resource's constructor and methods. I created it by having Claude start with a generated file and then fill in the methods.

[bvisness]

Well, maybe using the dev version of wasmtime wasn't such a great idea after all. Not really sure what that failing test is about nor how to proceed, but it seems like stuff is probably working fine on my end for C/C++/Rust.

[alexcrichton]

@dicej w.r.t.

           19: 0x4c39f2 - test-rust.core.wasm![async-lift]test:moonbit-stream-write-cancel/controller#start-peer-drop
        note: using the `WASMTIME_BACKTRACE_DETAILS=1` environment variable may show more debugging information
            1: BUG: switch item already set
        location: crates/wasmtime/src/runtime/component/concurrent.rs:6083
        version: 50.0.0-dev
        
        This is a bug in Wasmtime that was not thought to be reachable. A panic is
        not happening to avoid taking down the thread, but this trap is being injected
        into WebAssembly guests to prevent their execution. The Wasmtime project would
        appreciate a bug report with a copy of this message to help investigate what
        happened. If you're able to provide a reproduction, that would be appreciated,
        but it is not necessary to do so and instead indicating that this is reachable
        is a sufficiently actionable bug for maintainers to investigate.

you're likely interested in this -- and yeah @bvisness definitely not the cause of this change

[alexcrichton]

If you'd like, though, it seems ok to land this without tests for now and follow-up with tests later

[bvisness]

If you're ok with that, then I'll yoink the tests and CI changes and put them in a separate PR.

[alexcrichton]

Yeah that sounds good to me 👍