Skip serializing object entries w/ undefined value

[jbourassa]

Description of the change

Improve Javy's Value serializer compatibility with JSON.stringify:

• For Arrays, nullify non-JSONable values
• For Objects, skip entries with non-JSONable values

Why am I making this change?

Encoding a QuickJS value to JSON using the transcoder offers a nice performance gain over QuickJS's JSON.stringify, but differs in behaviour. This PR should partially close the gap.

$ echo "console.log(JSON.stringify({foo: undefined}))" | node
{}

Without this change, transcoding the above {foo: undefined} to a JSON string would result in {"foo":null}.

This PR fixes that by skipping skipping the deserialization of entries with undefined. This is a lossy conversion given serde data model doesn't know about undefined, and both the serde Unit and None data types are serialized as null in JSON.

Similar logic is applied to Array values, but in that case the values are nullified instead of skipped.

Checklist

• I've updated the relevant CHANGELOG files if necessary. Changes to javy-cli and javy-core do not require updating CHANGELOG files.
• [ ] I've updated the relevant crate versions if necessary. Versioning policy for library crates
• [ ] I've updated documentation including crate documentation if necessary.

[saulecabrera]

This change looks good to me, but it also got me thinking about other things:

• I think we should also check if values are functions and values are symbols? That's what the official JS JSON spec states:

undefined, Function, and Symbol values are not valid JSON values. If any such values are encountered during conversion, they are either omitted (when found in an object) or changed to null (when found in an array). JSON.stringify() can return undefined when passing in "pure" values like JSON.stringify(() => {}) or JSON.stringify(undefined).

• I'm wondering how this affects the messagepack implementation, if anything at all, given that this deserializer is used there too. I don't think that the messagepack crate is used at all in general, maybe another sensible option is to deprecate it.

[jbourassa]

I think we should also check if values are functions and values are symbols?

Good point, I can throw those in too. Hopefully it has limited impact on performance.

I'm wondering how this affects the messagepack implementation, if anything at all, given that this deserializer is used there too.

It will, but arguably that's a feature? I'd expect the msgpack implementation to be exactly like JSON.stringify, but msgpack encoded.

[jbourassa]

@saulecabrera I've now applied your suggestion of checking for more types. Sorry for the delay!

[saulecabrera]

Looks great, thanks!