Positional selectors in closest(), next() and the *Until() methods see a one-element set #118

Follow-up from #72. Assumes #72 is merged.

Problem

#72 made the set-returning methods (filter(), children(), not(), siblings(), nextAll(), prevAll(), parents()) evaluate their selector against the whole candidate set, so positional pseudo-classes count within the set. The walk-and-stop methods still test one node at a time, so the selector only ever sees a one-element set:

• closest(), parent(), next(), prev()
• the stop selector of nextUntil(), prevUntil(), parentsUntil()

$xml = '<?xml version="1.0"?><ul><li id="a"/><li id="b"/><li id="c"/><li id="d"/></ul>';

qp($xml, '#a')->nextUntil(':eq(1)');
// b, c, d: each sibling is tested alone, so :eq(1) never matches and nothing stops the walk

The per-node path is now memoized (so it is no longer slow), but the semantics differ from the set methods.

Options

1. Batch: collect each start node's walk into one candidate set, filter it once, then walk again stopping at the first member of the matched set. One parse per call, one definition of "match" across the trait. Prototyped in the Match selectors against the nodes in hand, not their descendants #72 review: same speed as the memo.
2. Document it: keep per-node semantics and state in the DocBlocks that positional selectors are not meaningful for these methods.

What jQuery 3.x returns for the same calls should decide between them. Option 1 is a behaviour change.