perf: presize result slice in getChildrenWithSiblingType

[jvoisin]

For the sibling types that collect every match (siblingAll, siblingAllIncludingNonElements, siblingPrevAll, siblingNextAll), do a cheap first-pass pointer walk to count the matches, then make the result slice with that exact capacity. This removes the repeated append-driven slice growth that dominated allocations on these hot traversal paths.

The Until cases are left untouched because counting would require running the user predicate twice, and the single-result Next/Prev cases have nothing to presize.

This drives Children/Contents/Siblings/Next*/Prev* through fewer allocations:

                   allocs/op vs base    B/op vs base
Siblings            -57.23%             -9.23%
SiblingsFiltered    -54.49%             -8.94%
NextAll             -59.82%            -10.04%
NextAllFiltered     -55.83%             -9.65%
PrevAll             -55.32%            -10.66%
PrevAllFiltered     -52.53%            -10.40%
ChildrenFiltered    -15.38%             -6.45%
Contents             -7.69%             -1.73%
geomean             -25.07%             -3.88%

The Until and single Next/Prev benchmarks are unchanged (bit-identical allocs/op), confirming the count pre-pass only touches the collect-all paths.

The quite verbose comment on top of the change is there so that future generations won't waste time wondering why this weird loop is here.