fix js codegen allowing underscore after decimal

[ptdewey]

Addresses #5124

Fixes invalid generation of JavaScript code in cases where floats contain underscores immediately before/after a decimal point (i.e. 1._23).
The changes made here use the parsed value of the float instead of the string representation in generation code. This does result in semantic float formatting in gleam code no longer being preserved in generated JavaScript.

For case statements, this is fixed as a byproduct of the changes made in #5118. (I'm marking this as a draft until that PR is merged and will add tests for this behavior specifically in a case statement)

[ptdewey]

Digging in a bit more, the compiler produces an error (LexicalErrorType::NumTrailingUnderscore) if a number has a trailing underscore (i.e. 1000_.1), but not when there is a preceding underscore. Would it make sense to produce an error for the preceding case as well? (this may be a tangential conversation in relation to this fix)

[lpil]

Thank you! Rather than render the float value to a string could you use the original string value please 🙏

[giacomocavalieri]

Rather than render the float value to a string could you use the original string value please

But using the original string value wouldn't fix the issue this PR is meant to fix. We're already rendering the float value to a string for patterns instead of using the original string value

[lpil]

But using the original string value wouldn't fix the issue this PR is meant to fix.

Aye, this work is to fix that by changing the output, and the easiest way would be to edit that string.

We're already rendering the float value to a string for patterns instead of using the original string value

Does that code have the same bugs as this one does? This PR is generating invalid JavaScript currently.

We can use the value here, but we need to ensure that infinity and nan are used in appropriate ways, which requires a bit more work.

[ptdewey]

Does that code have the same bugs as this one does? This PR is generating invalid JavaScript currently.

It may have the same issue, I don't think there is an explicit test against the infinity case.

We can use the value here, but we need to ensure that infinity and nan are used in appropriate ways, which requires a bit more work.

When I get a chance later I'll look deeper into the infinity issue.

[ptdewey]

Looks like the infinity issue also occurs in the case statements after #5118.

I created a new function for converting from an f64 to a Document, which specifically checks if the value is infinity, and if it is NaN, returning valid JS for each of those cases.
The NaN check is unnecessary with how the function is currently used, but I thought it made sense to add it anyway.

Expressions could likely be handled by modifying the original string, but for consistency I think this approach is cleaner (although there was an alternative version of the exhaustiveness checks in #5118 that still output strings in JS codegen).