Allocate buffers before work in boolean_kernels benchmark

[alamb]

Which issue does this PR close?

• Related to Consolidate bitwise operation implementations #8806
• Related to Speed up unary not kernel by 50%, add BooleanBuffer::from_bitwise_unary #8996

Rationale for this change

When working on improving the boolean kernels, I have seen significant and unexplained noise from run to run. For example, just adding a fast path for u64 aligned data resulted in a reported 30% regression in the speed of slice24 (code that is not affected by the change at all).

for example, from #9022

and              1.00    208.0±5.91ns        ? ?/sec    1.34   278.8±10.07ns        ? ?/sec
and_sliced_1     1.00   1100.2±6.53ns        ? ?/sec    1.12   1226.9±6.11ns        ? ?/sec
and_sliced_24    1.40    340.9±2.49ns        ? ?/sec    1.00    243.7±2.13ns        ? ?/sec

I also can't reproduce this effect locally or when I run the benchmarks individually.

Given the above, and the tiny amount of time spent in the benchmark (hundreds of nanoseconds), I believe what is happening is that changing the allocation pattern during the benchmark runs (each kernel allocates output), data for subsequent iterations is allocated subtlety differently (e.g. the exact alignment or some other factor is different).

This results in different performance characteristics even when the code has not
changed.

What changes are included in this PR?

To reduce this noise, I want to change the benchmarks to pre-allocate the input.

Are these changes tested?

I ran them manually

Are there any user-facing changes?

No, this is just a benchmark change

[alamb]

the main change is to allocate all the inputs arrays before running the benchmarks

I had to rename some of the variables anyways, so I took the opportunity to rename them to reflect the names used in the benchmark descriptions as well