[js-api] Fix AddressValueToU64's type errors

[f52985]

This PR fixes two type-related errors in the AddressValueToU64 algorithm.

The algorithm AddressValueToU64(v, addrtype) converts a JavaScript value to a WebAssembly u64 ..., by performing the following steps:

1. If addrtype is i32,
    1. Let n be ? ConvertToInt(v, 32, "unsigned"), where the destination type is associated with [EnforceRange].
    ...
1. If addrtype is i64,
    1. Let n be ? ToBigInt(v).
    1. If n < 0 or n > 2^64 − 1, throw a TypeError.
    ...

1. JavaScript value vs IDL value

v here isn't a JavaScript value, but an IDL value.

It's whatever the caller's own IDL-declared AddressValue argument resolved to after WebIDL's own argument-conversion step already ran.

Both ConvertToInt and ToBigInt are defined over genuine JavaScript values, so v needs converting back before either branch uses it:

1. Let V be v, converted to a JavaScript value.

Both branches then read V instead of v.

2. BigInt vs Mathematical value

The i64 branch's range check compares n (a BigInt bound the line above via ?ToBigInt) directly against the mathematical-value literals 0/2^64 − 1, with no conversion.

According to the ECMA-262 standard:

Numeric operators applied to mixed-type operands (such as a Number and a mathematical value) are not defined and should be considered an editorial error in this specification.

so the range check should be:

1. If ℝ(n) < 0 or ℝ(n) > 2^64 − 1, throw a TypeError.

[Ms2ger]

Annoying, thanks

[f52985]

All done, this reads better now. Thanks for the feedback!

[Ms2ger]

Thanks. Will leave to @rossberg to merge as well