Remove the `core` and `std` feature flags

[Michael-F-Bryan]

Motivation

The wasmer crate currently has std and core feature flags. The intent behind this is to allow wasmer to work in #[no_std] environments. To this effect, the wasmer crate has a std feature flag which is intended to guard anything that requires access to the standard library. We also have a core feature flag which is mutually exclusive with std, that switches things over to using polyfills (e.g. hashbrown instead of std::collections::HashMap).

This sounds good in theory, but it's quite broken in practice...

The std library is a super-set of core, so best practice is to define just a std feature flag and use it to add items to your API that depend on the standard library. Our core feature flag is redundant here and actually does more harm than good because its mutually-exclusive nature means adding wasmer as a dependency with --no-default-features will trigger random compile_error!()s scattered around the place because you need to explicitly add either --feature=std or --feature=core.

Additionally, as of 7602de3, the std feature flag is de-facto broken because we've never made CI check that the wasmer crate compiles with and without the std feature enabled. We have a number of dependencies which rely on std and the wasmer crate itself relies on std directly in several places, so I doubt this will be fixed (if it's even possible) without considerable work.

Proposed solution

My proposal is to remove the core and std feature flags and leave the code they protect enabled all the time.

The feature flags are broken, which means it should be fine to make them no-ops until we release Wasmer v5.0.

Additional context

This originally came up because I was trying to build the wasmer-wasix crate using cargo check --target=wasm32-unknown-unknown --features=wasmer/js,js --no-default-features and had compile errors because I forgot the --features=wasmer/std for the 50th time.

[theduke]

The intention was to get proper no-std support, but the original approach wasn't right, there are a lot of gaps, and currently the features just add noise.

Properly fixing up the feature would be a lot of work, and I don't think we can put that on the roadmap anytime soon.

So I concur with removing the features.