Summary

This PR enables the deserialization of JSON files using ou; inON parser, in particular, it implements the deserialization of rome.json.

The deserialization of JSON files is different from the deserializati; hereserde, here criticalost important parts of the new deserialization:

• it takes advantage of the error recovery of the parser, and the deserialization will be able to override/compute the parts of the JSON that are correct (in compliance with the AST emitted by the parser);
• if rome.jsonRome errors, rome will use its defaults for the errored sections and print a warning. This warning is shown for the command format and check. For the command ci, the process will exit with an error code.

rome_deserialize

I created a new crate called rome_deserialize. This crate has a generic logic to parse and deserialize a generic JSON file. This is do the followingne using:
' VisitNodgenetic generic trait that exposes some API to implement when visiting a node. It accepts a &mut self, and it shenforcedlemented against the type that should be deserialized; This trait is generic against Language;

• JsonDeserialize, which is a specialized type for JSON files that helps to kick-off the deserialization from a type that implements Default;
• deserialize_from_json, which accepts some source, ideally the JSON string, and it will parse it and deserialize it. The emitted result will contain the deserialized result and several diagnostics emitted during the parsing/deserialization phase;

I created a doc test that shows how deserialization should be implemented against a generic struct that contains a boolean.

This crate exposes a DeserializationDiagnostic.

rome_analyzer

There's a downside to this. The rule options are deserialized as they were different pieces of JSON files, so they are parsed twice and deserialised once (when we call the actual rule). The problem is that when we emit the error, the range and the source are incorrect.

We already had this issue before with serde, but here it is more evident, and I am sure we can fix it later. I don't think the issue is a show-stopper. After all, I just kept the logic as it was.

rome_service

The generation of the configuration of the rules changed. We don't rely on serde to deserialize the configuration, but we still use it inside the daemon, that's why it hasn't been removed. Also, we don't suppose serialization, and that is needed inside the daemon. Nevertheless, the shape of the structs has changed internally, but the main logic results in the same result.

Test Plan

I created new tests and updated the existing ones. The current rome_cli tests should still yield the same result while its diagnostics should be different.

Documentation

• The PR requires documentation
• I will create a new PR to update the documentation