Use nwsapi and dom-selector depending on the selector

[asamuzaK]

As a new approach, I suggest using nwsapi and dom-selector depending on the selector.

Process

1. Roughly parse the selectors.
2. If selectors are those that nwsapi can handle, let nwsapi do the work.
3. Else dom-selector takes over.

Benchmark

Test	main	patch
# selectors/complex-selectors/closest #	jsdom x 125,841 ops/sec ±0.60% (73 runs sampled)	jsdom x 118,441 ops/sec ±2.02% (70 runs sampled)
# selectors/complex-selectors/matches #	jsdom x 116,945 ops/sec ±9.76% (63 runs sampled)	jsdom x 115,750 ops/sec ±9.18% (66 runs sampled)
# selectors/complex-selectors/querySelector #	jsdom x 3.15 ops/sec ±2.79% (12 runs sampled)	jsdom x 3.22 ops/sec ±2.60% (12 runs sampled)
# selectors/complex-selectors/querySelectorAll #	jsdom x 2.95 ops/sec ±2.96% (12 runs sampled)	jsdom x 3.04 ops/sec ±1.75% (12 runs sampled)
# selectors/compound-selector/closest #	jsdom x 97,567 ops/sec ±0.70% (62 runs sampled)	jsdom x 123,345 ops/sec ±0.83% (63 runs sampled)
# selectors/compound-selector/matches #	jsdom x 651,071 ops/sec ±3.90% (55 runs sampled)	jsdom x 580,880 ops/sec ±1.02% (59 runs sampled)
# selectors/compound-selector/querySelector #	jsdom x 3.11 ops/sec ±2.88% (12 runs sampled)	jsdom x 2.79 ops/sec ±25.68% (12 runs sampled)
# selectors/compound-selector/querySelectorAll #	jsdom x 2.91 ops/sec ±1.08% (11 runs sampled)	jsdom x 2.89 ops/sec ±2.48% (11 runs sampled)
# selectors/simple-selector/closest #	jsdom x 312,611 ops/sec ±1.04% (56 runs sampled)	jsdom x 296,579 ops/sec ±0.92% (54 runs sampled)
# selectors/simple-selector/matches #	jsdom x 1,045,692 ops/sec ±22.10% (39 runs sampled)	jsdom x 912,957 ops/sec ±18.09% (40 runs sampled)
# selectors/simple-selector/querySelector #	jsdom x 3.27 ops/sec ±0.84% (12 runs sampled)	jsdom x 3.24 ops/sec ±1.15% (12 runs sampled)
# selectors/simple-selector/querySelectorAll #	jsdom x 2.80 ops/sec ±15.29% (10 runs sampled)	jsdom x 2.71 ops/sec ±22.58% (10 runs sampled)
# selectors/sizzle/querySelector #	18/273 fails. jsdom x 1.20 ops/sec ±7.88% (7 runs sampled)	13/273 fails. jsdom x 0.74 ops/sec ±7.79% (6 runs sampled)
# selectors/sizzle/querySelectorAll #	18/273 fails. jsdom x 0.89 ops/sec ±63.77% (7 runs sampled)	13/273 fails. jsdom x 0.75 ops/sec ±6.98% (6 runs sampled)

Note that the performance difference in the sizzle test is due to the selectors that failed has now been resolved and handled correctly.

Caveats

If the selectors are within Selectors level 3, performance should be about the same as before.
However, nwsapi has bugs in :not(), :is() and :where(). These are handled by dom-selector. Therefore, if you are already using these functions, e.g. :not(:is(.foo, .bar)), you may experience performance degradation.
The same applies to :indeterminate, :placeholder-shown and :scope.

[domenic]

As discussed in the other thread, I don't think this approach is right for jsdom. I want to incorporate a single selector engine, that uses a fast architecture.