Generalize the walk implementation

[RobinMalfait]

This PR generalizes the walk implementations we have. What's important here is that we currently have multiple walk implementations, one for the AST, one for the SelectorParser, one for the ValueParser.

Sometimes, we also need to go up the tree in a depth-first manner. For that, we have walkDepth implementations.

The funny thing is, all these implementations are very very similar, even the kinds of trees are very similar. They are just objects with nodes: [] as children.

So this PR introduces a generic walk function that can work on all of these trees.

There are also some situations where you need to go down and back up the tree. For this reason, we added an enter and exit phase:

walk(ast, {
  enter(node, ctx) {},
  exit(node, ctx) {},
})

This means that you don't need to walk(ast) and later walkDepth(ast) in case you wanted to do something after visiting all nodes.

The API of these walk functions also slightly changed to fix some problems we've had before. One is the replaceWith function. You could technically call it multiple times, but that doesn't make sense so instead you always have to return an explicit WalkAction. The possibilities are:

// The ones we already had
WalkAction.Continue // Continue walking as normal, the default behavior
WalkAction.Skip // Skip walking the `nodes` of the current node
WalkAction.Stop // Stop the entire walk

// The new ones
WalkAction.Replace(newNode) // Replace the current node, and continue walking the new node(s)
WalkAction.ReplaceSkip(newNode) // Replace the current node, but don't walk the new node(s)
WalkAction.ReplaceStop(newNode) // Replace the current node, but stop the entire walk

To make sure that we can walk in both directions, and to make sure we have proper control over when to walk which nodes, the walk function is implemented in an iterative manner using a stack instead of recursion.

This also means that a WalkAction.Stop or WalkAction.ReplaceStop will immediately stop the walk, without unwinding the entire call stack.

Some notes:

• The CSS AST does have context nodes, for this we can build up the context lazily when we need it. I added a cssContext(ctx) that gives you an enhanced context including the context object that you can read information from.
• The second argument of the walk function can still be a normal function, which is equivalent to { enter: fn }.

Let's also take a look at some numbers. With this new implementation, each walk is roughly ~1.3-1.5x faster than before. If you look at the memory usage (especially in Bun) we go from ~2.2GB peak memory usage, to ~300mb peak memory usage.

Some benchmarks on small and big trees (M1 Max):

We also ran some benchmarks on @thecrypticace's M3 Max:

In node the memory difference isn't that big, but the performance itself is still better:

In summary:

1. Single walk implementation for multiple use cases
2. Support for enter and exit phases
3. New WalkAction possibilities for better control
4. Overall better performance
5. ... and lower memory usage

Test plan

1. All tests still pass (but had to adjust some of the APIs if walk was used inside tests).
2. Added new tests for the walk implementation
3. Ran local benchmarks to verify the performance improvements

[RobinMalfait]

If you read this commit by commit, this will get replaced in future commits!

[RobinMalfait]

This is added because the generic walk doesn't skip context nodes.

[RobinMalfait]

This diff looks big, but it's mainly re-indents

[RobinMalfait]

The only reason these are uppercase is because they represent enum values. We don't have ADTs in JS sadly, so we work around it by having a function that returns a specific object.

All of them have a unique kind discriminant.

We already had Continue, Skip, Stop, and replaceWith. I then added Replace(…), ReplaceSkip(…) and ReplaceStop(…).

Open for suggestions for better names here.

[thecrypticace]

These names seem completely fine to me imo.

Like you could go with ReplaceAndSkip(…) or w/e if you wanted but I really don't think that is necessary. This perfectly readable as is.

I also dig the ADT-ish syntax here so also like the uppercase names 🤷‍♂️