Avoid using browser-specific features when building for WASM

[KernelFreeze]

Objective 🎯

This PR aims to improve the support for non-browser environments by introducing a new Cargo feature gate browser. This helps us prevent the usage of web-specific crates, such as wasm-bindgen, web-sys, wasm-bindgen-futures, js-sys and others when building for an environment like WebAssembly System Interface.

This ensures that Bevy remains a versatile game engine that can be used across a wide range of platforms and environments, without relying on browser-specific features that may not be available in other contexts, for example, embedding Bevy inside a WASI runtime for game extensions.

Overall, this PR seeks to enhance the flexibility and portability of the Bevy Game Engine, making it more accessible and easier to use for a broader range of developers and use cases.

Solution 💥

• This PR adds a new optional but enabled by default Cargo feature gate browser.

Changelog 👩🏻‍💻

• Added feature gate to bevy_app, bevy_asset, bevy_tasks, bevy_log and bevy_utils.
• Added cfgs to only use wasm-bindgen and other crates when available.

Migration Guide 🐛

• This PR is not a breaking change, and there is no need for users to migrate their code to support these changes.

Open Questions ⁉️

• How should we handle single-thread async tasks in WASI? We can't use wasm_bindgen_futures. For now, I used the multi-thread code with available_parallelism set to 0.
• Should we add the feature gate to crates like bevy_render and bevy_audio? I think it's unneeded because we can't use WGPU inside WASI.

[KernelFreeze]

Also, this fixes #4906.

[hymm]

is it possible to use target_vendor to detect compiling for wasi instead of a feature?

[KernelFreeze]

That's a really good idea, but I was thinking that perhaps some users might prefer to build for WASM targets without relying on the wasm32-wasi target or using browser-specific APIs, without more to add, I am open to use this method.

[hymm]

I was thinking that perhaps some users might prefer to build for WASM targets

Are there targets others than wasm32-unknown-unknown, wasm32-wasi, and wasm32-unknown-enscripten?

[KernelFreeze]

I was thinking that perhaps some users might prefer to build for WASM targets

Are there targets others than wasm32-unknown-unknown, wasm32-wasi, and wasm32-unknown-enscripten?

I think those are the only ones, but some users prefer to use wasm32-unknown-unknown and then write their own OS interface layer.

[mockersf]

Looks good! being able to run a Bevy app in CLI with wasmtime is nice. I would love to extend support of more Bevy crates, but that can happen later

[KernelFreeze]

Looks good! being able to run a Bevy app in CLI with wasmtime is nice. I would love to extend support of more Bevy crates, but that can happen later

Great to hear that. Adding support for more Bevy crates would definitely be a great addition. Let me know if you need any assistance in that matter with a follow-up PR, I'd be happy to help out, but I would need to know what any other crates could be useful in a WASM context.

[mockersf]

On the top of my head:

• bevy_asset even without file support, to have the asset server and the Handle types to manage procedurally generated assets, or asset retrieved somewhere else
• bevy_scene which should be easy once bevy_asset is done
• bevy_render to get the Mesh type for mesh manipulation. There were talks about moving the Mesh type to another crate to avoid pulling the whole renderer just to have it, but no real need for now

For now this PR needs another review before being merged