Allow v3, v4, v5 features on wasm32-unknown-unknown

[Expyron]

I'm submitting a feature

Description

The v3, v4, v5 features did not work on wasm32-unknown-unknown in a no_std context.

For v3 and v5, the md5 and sha1 crates are no_std if their default features are disabled, so they work on wasm32-unknown-unknown.

For v4, getrandom can work on any architecture if the root crate registers a custom implementation.

This is not a breaking change, as the other architectures (including stdweb and wasm-bindgen) are not impacted.

Motivation

I wanted to use this crate (especially the v4 feature) on a wasm32-unknown-unknown context that does not have stdweb nor wasm-bindgen.

Tests

The test suite unfortunately does not run on wasm32-unknown-unknown.
The v3, v4, v5 features work properly, as I was able to use them from a dependent crate.

[KodrAus]

Thanks for the PR @Expyron!

I’m a little unsure about committing to getrandom here by guaranteeing a registered implementation will work, but otherwise this seems totally reasonable to me!

[Expyron]

I also want to point out that getrandom will refuse to compile on an unsupported target if a custom function is not provided, with a clear error message:

error: target is not supported, for more information see: https://docs.rs/getrandom/#unsupported-targets

That error message would be preferable to the current behavior, which is that Uuid::new_v4() is not defined at all.

getrandom - Rust

API documentation for the Rust `getrandom` crate.

[lastmjs]

Is there anything holding this up? I'm starting to develop on DFINITY's Internet Computer, which is a custom WebAssembly environment, and it doesn't like like I can use UUID easily until this is fixed

[kinggoesgaming]

bors r+

[bors]

Build succeeded:

• continuous-integration/travis-ci/push