refactor(array): propagate allocators through builders

[gatesn]

Summary

Require array builder call sites to choose a buffer allocator explicitly while keeping the old APIs as deprecated compatibility shims.

Changes

• Add allocator-taking _in APIs and deprecate the allocator-free builder constructors.
• Take &BufferAllocatorRef at API boundaries; clone only when a buffer or builder retains it.
• Propagate the allocator through nested, dictionary, and offset-based string builders.
• Use ctx.allocator() in execution paths; use the static allocator only where no execution context exists.
• Add custom allocator coverage.

[codspeed-hq]

Merging this PR will degrade performance by 8.22%

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 1 improved benchmark
❌ 3 regressed benchmarks
✅ 2183 untouched benchmarks
⏩ 218 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	decompress[u64, (4000, 1024)]	70.8 µs	86 µs	-17.63%
❌	WallTime	filtered_owned_i64_avx512[OneNullInEight]	22.4 µs	26.1 µs	-14.24%
❌	Simulation	chunked_bool_canonical_into[(1000, 10)]	27.1 µs	30.6 µs	-11.47%
⚡	Simulation	allocate_drop_arrow[0]	456.9 ns	402.7 ns	+13.45%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing ngates/buffer-allocator-builders (542aed9) with develop (bffdca1)}

Footnotes

1. 218 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[robert3005]

No breaks please, can you add back old api and mark it deprecated. Users don't want the churn just because you need a new feature.

[gatesn]

I dunno… most callers will have an ExecutionCtx in scope and not pass it. In fact, shouldn't ArrayBuilders hold ExecutionCtx anyway so that you can extend_from_array?

[robert3005]

I am purely arguing from the churn POV, it would be ideal if we can avoid forcing people to update their builder usage when they upgrade vortex. I think we can remove it in 1-2 releases

[robert3005]

I think since this method wasn't widely used before we can break this ONE method so that we don't have builder_with_capacity_in_ref