Add float conversion tests

[AugustusHuang]

No description provided.

[jfbastien]

Confirming that Xuxing Huang is a member of the W3C CG. Thanks!

[rossberg]

lgtm

[AugustusHuang]

Picked +/-0, +/- INT_MAX, +/-1 to test Int2Float, 0, 1, +/- MOST-POSITIVE-DOUBLE(SINGLE)-FLOAT, +/- LEAST-POSITIVE-DOUBLE(SINGLE)-FLOAT to test reinterpretFloat2Int, some of the results of reinterpretInt2Float will generate NaN so I didn't add them. All tests have one or more random cases :)

[sunfishcode]

The wasm parser does recognize hexadecimal constants now, so you can write the constant directly now instead of writing it in decimal and having a comment :-).

[sunfishcode]

This looks good!

One thing to watch out for: Constants such as 2147483647, 9223372036854775807, and 1234567890 are not exactly representable as f32 values; the wasm parser is silently rounding them. This is obviously not ideal. Eventually we should implement hexadecimal float literal parsing, and then we'll probably convert most of these tests to use it, but if you want to be tidy in the mean time, it'd be nice to avoid values that need rounding.

If you're interested in writing more conversion tests, here are some further ideas :-) :

• Conversions with unsigned inputs will need to be tested with the maximum unsigned value of the type. For example, we'll need to test f32.convert_u/i32 against 0xffffffff and so on.
• Conversions involving floating point will need to be tested for correct rounding. For example, the trunc conversions are defined to round toward zero, so we should make sure that a positive number rounds down even when the nearest integer is up, and a negative number rounds up even when the nearest integer is down, and so on. For conversions that round to nearest, we should test that a positive number is rounded down to nearest, a negative number is rounded up to nearest, and a number halfway between two integers is rounded to the even integer.
• trunc conversions will need to test that values just outside the i32 range can be rounded into a valid i32 value.

We'll also eventually need to add -0, NaN, Infinity, and trapping cases, though as you noticed these aren't all convenient to do right now. I have some possible ideas for this in this branch, though there's discussion ongoing about them in #70.