fix wasm + no-std cargo interactions

[jbr]

This started as an extension of #863 disabling the build cache in ci and turned into an investigation of a cargo bug that pulls in wasm deps for no-std, breaking ci. The proposed fix in this pr also closes #823

[jbr]

@dignifiedquire It seems like this sledgehammer-fix resolves the macos issue, but I think the no-std failure is real. I get it locally as well.

Edit: I think maybe this is a cargo bug? 🙃

$ cargo check --no-default-features --features alloc --target thumbv7m-none-eabi -Z avoid-dev-deps --verbose
       Fresh pin-project-lite v0.1.7
    Checking futures-core v0.3.5
     Running `rustc --crate-name futures_core --edition=2018 /Users/jbr/.cargo/registry/src/gb.xjqchip.workers.dev-1ecc6299db9ec823/futures-core-0.3.5/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata -Cembed-bitcode=no -C debuginfo=2 --cfg 'feature="alloc"' --cfg 'feature="default"' --cfg 'feature="std"' -C metadata=6587bfddd05ac72e -C extra-filename=-6587bfddd05ac72e --out-dir /Users/jbr/code/async-std/target/thumbv7m-none-eabi/debug/deps --target thumbv7m-none-eabi -L dependency=/Users/jbr/code/async-std/target/thumbv7m-none-eabi/debug/deps -L dependency=/Users/jbr/code/async-std/target/debug/deps --cap-lints allow`
error[E0463]: can't find crate for `std`

note the --cfg 'feature="std"' — that makes no sense. Somehow --no-default-features is getting ignored and std is getting added back in???

Further digging:
Disabling the target_arch = "wasm32" dependencies and dev-dependencies lines fixes no-std. Somehow they're getting enabled even though they shouldn't be active.

Proposed fix:

This PR includes changes that would fix several issues in async-std regarding wasm, but has a cost: Wasm users will have to enable a mandatory wasm feature. This also would address the issue where wasm deps were getting pulled in on non-wasm platforms (#823)

[dignifiedquire]

Got it back working without introducing a feature, so closing this #863