fix(crypto): validate that digest length must be an integer between 0 and isize::MAX

[jeremyBanks]

Currently, if we call crypto.subtle.digest/.digestSync with a variable-length hash algorithm and length that is...

• too large to fit in 32 bits/greater than Rust's usize::MAX for WASM: it will be truncated, usually to 0, producing an incorrect result.
• too large to fit in in Rust's isize::MAX for WASM: it will trigger an internal capacity_overflow error from Rust's Vec.
• negative: it will overflow and wrap around, usually resulting in a very-large value that will trigger an internal capacity_overflow error from Rust's Vec.
• not an integer: it will be truncated to the nearest integer value.

Some of this behaviour is a result of the JS-WASM translation layer, so this PR adds a check on the JavaScript side to throw a RangeError in these cases, before calling the Rust/WASM (which already checks that the length is valid for the specific algorithm being used).

This also resolves #3798, which describes how our tests cases were already expecting errors for these cases, but the test logic had a bug that was causing the assertion errors to be suppressed. This fixes that test logic.

One might argue that this is a BREAKING change since it produces an observable change in behaviour (at least for the non-integer case). I'm not sure it's a significant enough to count, but feel free to rename this PR to indicate that it's BREAKING if you disagree.

[jeremyBanks]

These canary test failures don't seem to be related to my changes..?

[iuioiua]

Great work! Couple of nits.

[iuioiua]

LGTM! Thank you, @jeremyBanks. Thorough work, as per usual.

[kt3k]

LGTM