Vendor getrandom 0.3

[hanyuone]

This PR implements the "first PR" outlined here in #2341:

First PR: Vendor the getrandom wasm_js.rs backend along with wrappers in lib.rs into rand/getrandom/{lib.rs,backends.rs,wasm_js.rs}. Compile and use the vendored implementation only if the target is wasm32 and wasm32_unknown_unknown_js is enabled. Use getrandom 0.3 otherwise.

I needed to add error.rs and utils.rs as well, since the Error struct and some utility functions were required by the other files.

Currently, running ring on wasm32-unknown-unknown requires the getrandom_backend config variable to be set in order for getrandom to compile properly, but making the ergonomics smoother is outside the scope of PR.

[briansmith]

Thanks for taking this on. Please post a new version with these changes and squash them all into one commit with a good commit message. Then I will review the updated version by diffing it with upstream. Also, please use an upstream commit that corresponds to a crates.io release of getrandom.

[hanyuone]

Sorry for getting back to this late - all the points should be addressed, and I'm using the upstream commit corresponding to v0.3.3 on crates.io. Once you've confirmed everything is good, I'll squash everything down to one commit.

With ring, are we certain that we'll only ever be using getrandom_backend="wasm_js"? If so, then I can get rid of the getrandom_msan optional code in lib as well.

With v0.3.4, the getrandom_backend config flag is now default - would that change our approach to updating getrandom?

[hanyuone]

@briansmith Have you had a chance to look at this yet?

[hanyuone]

@briansmith With #2756, should this PR be closed?

[briansmith]

@briansmith With #2756, should this PR be closed?

I hope we'll be able to merge #2756 and avoid having to vendor getrandom, but I won't know for sure until I actually prepare a release. getrandom 0.4 increases the MSRV substantially but it looks like the MSRV increase is good for other reasons anyway.

[hanyuone]

Closing because #2756 is merged.