JavaScript visitor API for custom transforms

[devongovett]

This adds a visitor API to the node bindings which enables custom transforms to be written, similar to custom PostCSS plugins. I've re-created several popular PostCSS plugins in the tests to verify that it is possible to do so.

The API tries to let you be as specific as possible about what types of values you care about by defining functions for specific value types, property and rule names, etc. This lets us call from Rust into JS as little as possible, which helps with performance. An example plugin to convert pixels to rems is about 6x faster than an equivalent PostCSS plugin. JS visitors do have a cost however - it's about 2x slower than with no visitors. So this API is there when you want to do something custom, but transforms for standard CSS features should be implemented in Rust as part of core.

At the moment, a visitor runs in a single pass over the AST. We could later add support for multi-pass transforms if needed, but would be nice to avoid if possible. To support multiple visitor "plugins", there is a composeVisitors function included which combines multiple visitors into one on the JS side, which can then be passed to the Rust implementation. We try to make the order of the visitors not matter as much as possible. Each visitor has the opportunity to visit each value once. If a visitor returns a new value for a node, that value is visited by the other visitors but not again by the original visitor that created it. We keep track of which visitors have been visited and mutated the value to avoid infinite loops.

Implementation wise, it relies on Serde to serialize and deserialize parts of the AST into JS objects as needed. We also use the schemars crate to generate a JSON schema definition from the Rust types, which is then converted into TypeScript. A bulk of the changes in the PR are related to this, and making the AST types nicer to work with in JS.

One downside is that the binary size of lightningcss gets significantly larger with this feature - mostly due to serde derived implementations. I think the feature is worth it to include by default - but if we need to, we could always have an additional "lite" build available for users with strict size requirements that don't need this feature.

API feedback welcome! Check out the tests for some examples.