ci: shard the benchmark workflow across parallel jobs

[zeroshade]

Rationale for this change

The Benchmarks workflow runs go test -bench=. ./... sequentially across every
package. Because go test's -timeout is applied per package, the wall-clock time
is the sum over all packages — recent main runs have taken roughly 3.3 hours
(198–208 min).

What changes are included in this PR?

Split the benchmark run so it can be parallelized, then combine the results into a
single upload:

• ci/scripts/bench.sh — adds --run (benchmark a subset of packages, writing
  raw output to a .dat) and --aggregate (merge one or more .dat files into a
  single bench_stats.json via gobenchdata) modes. The existing
  bench.sh <dir> [--json|-json] interface is unchanged, so nothing else that calls
  it needs to change.
• ci/scripts/bench_shard.sh (new) — prints a GitHub Actions matrix that buckets
  the packages containing benchmarks into N shards.
• .github/workflows/benchmark.yml — reworked into three jobs: setup (compute
  the shard matrix) → benchmark (matrix; each shard runs its packages and uploads
  its .dat) → combine (download all .dat, aggregate into one bench_stats.json,
  and — only on push to main — upload once to Conbench).
• ci/scripts/bench_adapt.py — reuses an existing bench_stats.json (produced by
  combine) instead of re-running the whole suite.

Because the shards are merged into one JSON and uploaded once, Conbench still sees a
single run (no run_id fragmentation).

Are these changes tested?

Locally:

• shellcheck clean on both scripts; actionlint clean on the workflow; py_compile
  OK on bench_adapt.py.
• Verified the split→merge end to end: ran --run on two packages, then --aggregate
  produced one bench_stats.json containing both suites, in the exact shape
  bench_adapt.py consumes.
• The legacy bench.sh <dir> --json path still runs → aggregates → cleans up.

Opened as a draft to exercise the reworked workflow in CI end to end (it triggers
on changes to these files).

Are there any user-facing changes?

No. This only touches CI / benchmark tooling.

Notes / follow-ups

• Sharding is currently round-robin by package, not runtime-weighted, so a single
  shard can hold two heavy packages (e.g. arrow/compute + parquet/internal/encoding)
  and become the long pole. The per-package -timeout (40m) remains the hard floor for
  any single package. Once this runs, per-shard timings can seed a runtime-weighted
  split or tune the shard count.