Build the QSA wrapper argument list in one allocation

[jdalton]

The wrappers install() puts on the DOM prototypes forward their arguments as a slice concatenated with the resolver, which allocates twice for a call carrying at most three arguments. Sizing the list by arity in one allocation is 1.85x on an installed querySelector for a cheap selector, and invisible on an expensive one.

Detail, and how it was checked

The wrappers install() puts on the DOM prototypes forward their arguments to parseQSArgs as [].slice.call(arguments).concat(resolver), which allocates twice for a call that carries at most three arguments. argsWith() sizes the list by arity in a single allocation, unrolled to eight and falling through to the general form beyond that.

Measured in isolation, building the list drops from ~113ns to ~9ns, and with the apply included from ~119ns to ~14ns.

End to end in Chromium, three rounds with the order swapped, an installed querySelector(#root) against a 200-element document:

	round 1	round 2	round 3
before	175 ns	174 ns	168 ns
after	95 ns	92 ns	90 ns
before, the wrapper alone	98 ns	97 ns	94 ns
after, the wrapper alone	19 ns	17 ns	17 ns

That is 1.85x on a cheap query, where fixed overhead is most of the call and the wrapper was 56% of it. On an expensive one it disappears into the query: the same change against a 200-match p.x is ~1% of 11.7us and not separable from run-to-run noise.

Extracted from #167 as a standalone change: one file, applies to master on its own, and checked against the benchmark fixture to confirm every selector still agrees with the native engine.

References: the spec, the browser source, and what each part was reasoned from

This patch applies to master on its own. The sixteen in this series were checked by cherry-picking them onto master one after another, in this order and in reverse, and all sixteen land without a conflict.

• MDN: arguments — the arguments object these wrappers forward.