fix: avoid BinaryViewBuilder ReserveData(0) allocating a block

[fallintoplace]

Summary

Problem

BinaryViewBuilder.ReserveData(length) always delegates to multiBufferBuilder.Reserve(length). In practice, Reserve(0) can still create a full default block in the current implementation, which triggers an unnecessary allocation for batches that keep all-view data inlined.

Change

• Early-return from BinaryViewBuilder.ReserveData when length == 0.
• Skip calling into blockBuilder.Reserve(0) for that path.
• Add a regression test with a no-allocation allocator to assert that reserving zero data length does not allocate a view-data block.

Impact

• Removes unintended memory churn (roughly a full block, e.g., 32 KiB) for the zero-length reservation case.
• Improves performance for all-inline view builders in small/empty-batch heavy workloads.
• No behavior change for non-zero ReserveData calls.

Testing

• Added regression test in this PR covering zero-length ReserveData allocation behavior.
• Local test run not performed in this PR (test is narrowly scoped and covered by the new assertion).

[zeroshade]

The ReserveData(0) short-circuit is reasonable, but the branch doesn't compile on its own:

arrow/array/binary_test.go:705:28: undefined: binaryViewNoAllocAllocator
FAIL	github.com/apache/arrow-go/v18/arrow/array [build failed]

binaryViewNoAllocAllocator is introduced in #888 — it's not on main and not in this PR. Please rebase this on top of #888 (so the helper exists) or add the helper here. Once it builds, the guard + test look good.

Verified by checking out the PR head and running go test ./arrow/array/.

[zeroshade]

Rebased onto main now that #888 has merged (it introduced checkBinaryViewValueSize and the binaryViewNoAllocAllocator test helper). Resolved the ReserveData and binary_test.go conflicts, and confirmed go build/go test ./arrow/array/ are green (both TestBinaryViewBuilderReserveData0DoesNotAllocate and the oversized-value guard pass). This should now compile — over to CI.