Support wasip3 WIT changes in WAC parser

[ryan-surname-p]

Closes #180 (I thought, it appears to be closed so maybe this enhances 180?)

This PR brings the WAC source language up to date with the WIT additions needed to express wasip3 components.

Since updating wasm-tools both wac-types and wac-graph have added support for WIT keywords async, stream, future and error-context.

What's left is to bring wac-parser up to date with wac-types and wax-graph.

[fibonacci1729]

Sorry about closing #180 (that was my mistake)!

This is great, thanks for tackling this!

[ryan-surname-p]

Sorry about closing #180 (that was my mistake)!

This is great, thanks for tackling this!

no problem at all, I was worried I was missing something haha

[fibonacci1729]

@ryan-surname-p should i review this in its current state or are you planning to bring wac-parser up-to-date first?

[ryan-surname-p]

Hey @fibonacci1729, I was actually under the impression that by updating the Lexer, AST, and AST Resolver to support the wasip3 keywords (async,stream, future, and error-context) I had done just that.

This bridges the gap between wac-parser and the wac-types / wac-graph backend.

The backend already understood these keywords. What was missing was purely the frontend surface to write them in a .wac file. So this PR just wires the frontend up to the capabilities the backend already had.

So I'm ready for a review as-is and if I missed something important please call it out and I'll take care of it as best I can.

[fibonacci1729]

nit: Positional booleans are mildly error-prone at call sites. I would consider adding something like:

#[derive(Clone, Copy, PartialEq, Eq)]
enum Async { No, Yes }

impl From<bool> for Async {
    fn from(b: bool) -> Self { if b { Async::Yes } else { Async::No } }
}

But again, ill leave this up to you!

[ryan-surname-p]

I didn't love how this came out so I left it as is for now, if you feel strongly about it though I can go ahead and add the async type.

[fibonacci1729]

This looks great!

Just two nits and few things to consider/note:

1. It would be nice to add a negative test asserting that error-context<u8> (error-context takes no payload) or an empty stream<> is rejected.

2. This update is technically a breaking change given the new reserved keywords so we just need to remember to call this out in the release notes and cut the next release as v0.11.0.

[ryan-surname-p]

This looks great!

Just two nits and few things to consider/note:

1. It would be nice to add a negative test asserting that error-context<u8> (error-context takes no payload) or an empty stream<> is rejected.
2. This update is technically a breaking change given the new reserved keywords so we just need to remember to call this out in the release notes and cut the next release as v0.11.0.

1. Added negative tests for for empty stream/future payloads and unexpected error-context payload.
2. What's the best way to handle this, would you like me to add "breaking" to the commit message?

[fibonacci1729]

What's the best way to handle this, would you like me to add "breaking" to the commit message?

@ryan-surname-p I don't think anything is required on your end -- since we are v0 still, i'll just add a note to the release notes when we cut. In practice, I don't imagine anyone will be affected but to satisfy the semver gods...