feat: deserializer POC

[Conaclos]

This PR presents a POC to write for write once deserialization code for biome configurations.
To demonstrate the feasibility of this, I only wrote the serialization of the configuration of useNamingConvention rule.

POC v1 is in commit 1.
POC v2 is in commit 2.

The system relies on two main traits defined in biome_deserialize::visitor:

• NodeVisitor (DeserializationVisitor in POC v2) which allows visiting a value (array, map, boolean ,string, ...)
• DeserializableLanguage that implements the specific code for every language

NodeVisitor is implemented by bool, String, Vec<T>, NamingConventionOptions and EnumMemberCase.
DeserializableLanguage is implemented by JsonLanguage (see biome_deserialize::json).

DeserializableLanguage requires the implementation of a method named deserailize_value that takes a visitor and a value (synatx node) as parameters.
An implantation of this method has to call the corresponding visit_ method of the given visitor according to the type of the given node.

For convenience, the POC v2 provides a third trait named Desrializable with a method desrializable. The trait is implemented by SyntaxNode<L>.

In contrast to the first POC, POC v2, the visitor is not implemented for the instance of a type, but for the type itself. Instead of modifying the visited instance, it produces an instance of the visited type. This removes the constraint to have types that implement Default. This also provides a cleaner way to deserialize enums and other values.

POC v2 also introduces a new struct DeserializationDiagnostics that simplifies creation of a diagnostic and ensure that users use a curated list of diagnostics.

In comparison to the previous approach we can easily add a config language by implementing DeserializableLanguage.
We also avoids leaking representation information outside a type. Only the type know how deserialize itself.

[Conaclos]

Closing in favor of #683