feat(engine): support f32 TryFromJs

[AayushMainali-Github]

Fixes #5360.

Summary

• implement TryFromJs for f32
• support both integer-backed and floating-point JavaScript numbers
• return a TypeError for non-number values
• cover integers, fractions, infinity, and invalid input

Testing

• cargo test --workspace
• cargo check --workspace --all-targets
• cargo test -p boa_engine
• cargo clippy -p boa_engine --all-targets -- -D warnings
• cargo fmt --all -- --check

[hansl]

I have a few issues with this one, and they're more philosophical than technical. Two points:

1. f32 does not hold 32-bit integers fully. So there can be loss of precision very early on. f64 has no issues with JS, since JS numbers are f64.

2. It is essentially the same as converting an f64 to an f32, but the developer (API user) actually sees that there is a loss of precision. Rust in general is a language that prefers explicit conversions to implicit ones.

So in the end I'd rather a user converts a JS type to f64, then explicitly convert it to f32 than doing the implicit conversion and people coming to us.

I'm willing to hear a counterargument, but this is actually the reason we've not implemented TryJsInto for f32 in the past. It wasn't due to technical restrictions.

There is a slight loss of performance when doing integers JsValues to f64 to f32 conversions instead of doing f32 directly, but that's so minimal that I don't think it would matter in a real application.

[AayushMainali-Github]

Yeah, that's fair.

One small thing though: TryIntoJs is already implemented for f32 (and From<f32> for JsValue too), so you can go f32 -> JsValue today but not back. If explicitness is the rule, that direction is arguably the inconsistent one. Not pushing for it, just flagging in case the asymmetry bugs you.

Either way I'll close this. Want me to do a quick docs PR instead saying f32 is left out on purpose, with f64 + explicit as f32 (or from_js_with in derives) as the recommended path? Saves the next person from filing the same issue.