Add a new type Convert<> to convert values

[hansl]

This can be used to transform values in to converted versions of Rust types by using the type system and TryFromJs.

Also added a JsString conversion for TryFromJs. These methods are going to be useful when #3773 goes in (but this PR nor that one depend on each others).

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 29 lines in your changes are missing coverage. Please review.

Project coverage is 50.19%. Comparing base (6ddc2b4) to head (645b5e5).
Report is 126 commits behind head on main.

Files	Patch %	Lines
core/engine/src/value/conversions/convert.rs	0.00%	17 Missing ⚠️
core/engine/src/value/conversions/try_from_js.rs	0.00%	12 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3786      +/-   ##
==========================================
+ Coverage   47.24%   50.19%   +2.95%     
==========================================
  Files         476      457      -19     
  Lines       46892    44851    -2041     
==========================================
+ Hits        22154    22513     +359     
+ Misses      24738    22338    -2400     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jedel1043]

I think this shouldn't be called Coerce, since it's not really an implicit conversion. Instead, it should be called Cast<T>, which makes sense as a name for an explicit conversion.

[hansl]

Coerce (I was hesitating with Coerced) is the proper JavaScript term though when doing implicitly. When explicitly doing Number("123") it is called type conversion, so I'd be fine with Convert.

Cast in Rust is explicitly using ... as ... which is different than JavaScript, so I'd suggest not using that word. Notably this new type can fail when the original type is utterly impossible to cast (NaN to i8 for example), which is impossible with a (Rust) cast.

WDYT?

[jedel1043]

Yeah, Convert is much better.

[hansl]

@jedel1043 ping for this. This is ready to review.

[jedel1043]

Looks great! Just a small nitpick that doesn't block merging.

[HalidOdat]

I was thinking maybe we should add this logic to the TryFromJs instead of having a separate struct and just using the try_from_js directly:

let int = i32::try_from_js(&JsValue::from(10), context)?;

Is there any benefit to having a separate struct?

[jedel1043]

The problem is that TryFromJs has "lossless" semantics, which means that it only succeeds if the output type is roughly the same as the JsValue type (no to_string, to_number, to_boolean, etc).
If we want to do the change you're proposing, we would have to change the semantics of TryFromJs, and declare that it allows "lossy" conversions.

I tend towards not doing that because I don't really like to have implicit conversions in Rust APIs, but we could discuss with the team if this is a behaviour we want from TryFromJs.