Move "match these nodes against a selector" into DOMTraverser instead of NodeMatcher #116

Follow-up from the /simplify pass on #72. Assumes #72 is merged.

Problem

The question "which of these nodes, taken as candidates themselves, match this selector?" is answered in three places, each building an initialized DOMTraverser by hand:

• QueryPath\Helpers\NodeMatcher (added in Match selectors against the nodes in hand, not their descendants #72), used by is(), filter() and the traversal methods
• DOMTraverser::applySetFilter(), for :not()/:has()/:matches() with a positional argument
• DOMTraverser\PseudoClass::has() (and so isNot())

NodeMatcher only works because it knows engine internals: that the bare true constructor flag means "treat this set as the candidates", that the scope node defaults to the document element, and that the traverser returns document order and must be re-walked to restore the caller's. A change to any of those in DOMTraverser can silently break the Helpers copy.

Proposal

Give the engine a public entry point, e.g. DOMTraverser::filterNodes(SplObjectStorage $nodes, string $selector): SplObjectStorage (optionally on the Traverser interface), that preserves input order. Point NodeMatcher, applySetFilter() and PseudoClass::has() at it, and reduce NodeMatcher to the per-call memo or remove it.

No intended behaviour change. Worth checking separately while in there: PseudoClass::has() tests the node itself in initialized mode, which reads more like "matches" than CSS :has()'s "has a matching descendant".