[lemire]

This PR makes Contains faster in both the root package and roaring64.

Changes

• Type switch in Bitmap.Contains instead of a dynamic interface call. This also lets the bitmap-container bit test inline.
• Dedicated runContainer16.contains: a branchless search over interval starts, then a single key - start <= length check. Before, it went through search → searchRange, which returns three values and counts comparisons.
• Lower-bound key and array search (searchUint16, plus a uint32 version in roaring64): no early exit on equality (rarely taken, and it costs an extra branch per step), finished by a linear scan of the last 16 elements. It's used for the key lookup in Contains and in arrayContainer.contains. Other callers of binarySearch are unchanged.
• New benchmarks: BenchmarkContains and BenchmarkContains64.

Results

Median ns/query, 4096 random queries (half hits, half misses), with the variants measured side by side in the same process. Hardware: Apple M4 Max (arm64) and Xeon Gold 6548N (amd64, pinned with taskset).

case	M4 Max	Xeon
run containers (16 or 1000 runs)	−63% to −70%	−69% to −70%
bitmap containers, 64 keys	−13%	−30%
array containers (64 or 4000 values)	−15% to −17%	−14% to −15%
many sparse keys (64 or 4096)	−15% to −18%	−4% to −10%
mixed, 1024 containers	−18%	−24%
roaring64 key search (8 to 16384 keys)	−3% to −18%	−5% to −18%

No case was slower on either machine.

Not included

A fully branchless key and array search is another 30–50% faster on the Xeon but 50–70% slower on the M4. Go won't emit CMOV/CSEL for a value carried through the loop, so the branchless loop has to wait for each load in turn. That could be a follow-up in an amd64-only file with a generic fallback, after measuring on a Neoverse arm64 server.

go test ./... passes.