Default benchmarks to the async memory resource

[vuule]

nvbench_fixture.hpp defaults --rmm_mode to pool. Recently we've been recommending and defaulting to async mr use in production. We should align the benchmarks with the recommendation.

As a part of this, we should address any major performance issues this switch exposes:

• ORC writer: up to seven times slower with --rmm_mode async, due to the large number of allocations.
• segmented_bitmask_and: the API is set up such that these allocations cannot be avoided; opened Reuse existing null masks when superimposing struct nulls onto children #23484 to reduce the internal use of segmented_bitmask_and.

[vuule]

Surveyed all 62 NVBench suites (362 benchmarks) under pool and async on A100 80GB / CUDA 12.9, then re-ran the 22 suspects with default stopping criteria for real noise bounds.

Only two code paths are genuinely allocation-bound, and both would need fixing before the default switch:

benchmark	async/pool	worst config	allocs per call
orc_write_encode	1.59x	5.05x (STRUCT, cardinality=0)	10,163
segmented_bitmask_and	1.53x	1.85x (10k segments)	10,021

Both worst cases are outside combined measurement noise. Nothing else in libcudf is close: the next highest allocation count I measured is merge at 456 per call, and the Parquet writer manages 24 for a comparable write because it suballocates page buffers out of two arenas.

nsys confirms the mechanism — the async resource forwards every allocation to the driver at about 1.3 us, so 10,000 allocations is 10-20 ms of pure API time per call.

Every other benchmark that looked bad turned out to be the fixture's resource configuration rather than cuDF code — details in the next comment.

[vuule]

Worth separating from the code issues: the async-vs-pool mostly disappears for 20 out of 22 benchmarks when a large release threshold is used with the async mr: cuda_async_memory_resource{std::nullopt, rmm::percent_of_free_device_memory(50)}.

In addition, several benchmarks become faster than pool:
ndsh_q5 2.41x → 0.58x, match_keys 1.25x → 0.61x, structs_scan 1.07x → 0.75x. The NDS-H
queries, the only whole-pipeline workloads in the suite, all end up ahead.

@GregoryKimball @bdice Have we considered setting this threshold in the benchmarks? Do we recommend this to the customers?

[vuule]

Looked into segmented_bitmask_and - the allocations are intrinsic to the API design, since it returns a vector of device_buffers. Opened #23484 to avoid its use internally, but we can't avoid the numerous allocations without changes in the API. IMO this should not block the default mr choice in the benchmarks.
CC @shrshi