DPL: preparing for SlotArena migration - #15673

A timing benchmark cannot tell a storage-layout regression from a busy machine.
Count allocations instead: with eight inputs, relaying every input plus the
consume costs 18 allocations, and that number must not grow when the way a slot
holds its messages changes. The messages are built before the counter is armed,
so what is measured is the relayer rather than fair::mq.

The global operator new replacement only counts while a test arms it, so the
rest of the binary is unaffected.

The relayer tests and benchmarks reach into the consumed record with .size() and
.at(), which pins them to the record being a vector. Both operator[] and a
count_inputs pipe work on anything the relayer might hand back -- a vector of
per-input sets, or an arena holding them in one buffer -- so a change of storage
leaves this code untouched instead of rewriting thirty call sites.

Every existing benchmark here uses one or two inputs, which is exactly the
regime where per-input storage costs nothing to speak of, so none of them can
see a change to how a slot holds its messages. Sweep 1/8/32/128 instead.

Note this is the only benchmark using consumeWhenAll, which looks the
TimesliceIndex up in the service registry (CompletionPolicyHelpers). The others
use consumeWhenAny and never do, which is why BenchmarkServices does not
register it and why it has to be registered here -- without it the benchmark
throws at every input count, including one.