feat: allow custom fiber API impls on unsupported arches

[rvolosatovs]

Add support for custom embedder-supplied fiber implementations, similar to e.g. custom-virtual-memory feature and others that already exist.

I'm not sure whether custom-fiber or custom-stack-switch is more appropriate, went for the one matching the crate name.

For my concrete use case, this is sufficient to allow running Wasmtime with cranelift in interpreter mode using Pulley with async/component-model-async features enabled, compiled to wasm32-unknown-unknown with a bit of JS glue based on JSPI in the browser or node.js

[rvolosatovs]

I'm not sure if this should be gated by custom feature, but the comment in stackswitch states:

   // No support for this platform. Don't fail compilation though and
   // instead defer the error to happen at runtime when a fiber is created.
   // Should help keep compiles working and narrows the failure to only
   // situations that need fibers on unsupported platforms.

so this seems consistent

[alexcrichton]

Sounds reasonable to me, thanks!

Structurally though I'd like to plumb this a bit differently to ensure this shows up in the wasmtime-platform.h header file. That header is generated from this file and is the current source-of-truth for "wasmtime may externally rely on these things" and provides a nice place to document things as well.

Now if these C API definitions were added over there they wouldn't actually be usable in wasmtime-internal-fiber due to crate dependencies, but that's also fine to have them duplicated here. Basically, can you add these function definitions over there, document them as to their purpose, leave a provisional comment in both locations saying "hey this is duplicated over there keep them in-sync", and then regenerate the header file?