Port wasmtime-fiber to no_std and allow async feature in no_std Wasmtime.

[cfallin]

This PR allows a no_std Wasmtime build to be configured with the async feature. (Previously, a minimal no_std configuration could only run with sync entry points, without suspending of stacks.)

The main hurdle to this support was the wasmtime-fiber crate. Fortunately, the "unix" variant of fibers was almost entirely portable to a no_std environment, owing to the fact that it implements stack-switching manually in assembly itself. I moved the per-ISA implementations to a shared submodule and built the nostd platform backend for wasmtime-fiber with a stripped-down version of the unix backend.

The nostd backend does not support mmap'd stacks, does not support custom stack allocators, and does not propagate panics.

I've updated the min-platform example to ensure this builds but have not yet actually tested it (I am in the middle of a larger porting effort); hence, a draft PR for initial feedback.

[cfallin]

cc @alexcrichton -- I think you're on vacation now but I'd be very curious what you think of this in general!

[alexcrichton]

This all looks quite reasonable to me, happy to see this merged 👍.

Could you also add a cargo test -p wasmtime-fiber --no-default-features in CI? I generally try to make sure that if there's nontrivial code added with no_std/etc (as is the case for the nostd.rs file here) that we have some at least smoke testing of what's going on. I think that this should be testable when the std feature is disabled? (might have to conditionally enable/disable some panicking tests, and it's ok to use std in tests just want to be sure to test nostd.rs somehow)

[cfallin]

Updated and out of draft mode now; thanks!

[alexcrichton]

Is it possible to add a `cargo test -p wasmtime-fiber --no-default-features to CI as well?

[cfallin]

Sure thing, done!

[cfallin]

The CI failures are fairly perplexing -- the only failing job I see is "report failure on cancelation", and a bunch of other jobs are canceled midway through their runs. @alexcrichton any ideas?

[alexcrichton]

This happened on another PR the other night and I couldn't figure out what was happening. I then re-queued in the morning and it merged so I assumed it was a transient failure in CI infrastructure... Let's see if that still holds true?

[alexcrichton]

I've pushed a commit to run full CI on this PR where the PR run can't cancel itself, so let's see what happens...

[alexcrichton]

Bleh ok so this is a known issue (at least to me) on github actions. For the merge queue there's no way to cancel a failed job so our main.yml self-cancels whenever a job fails. This works fine on all platforms except Windows. On Windows self-cancelling sometimes gives you a big red X on the job and sometimes gives you the icon of "this was cancelled by someone else". Basically there seems to be a race of the self-cancel and the job actually failing.

In any case it's the Windows build. Just some minor things to update.

[cfallin]

Ah, that was entirely unintuitive, GitHub CI user-interface! Thanks for working that out.