Let a scan limit how many splits it decodes at once #11124

Problem or motivation

A scan keeps 4 × available_parallelism() splits in flight (RepeatedScan::execute_stream), and nothing in ScanRequest, JNI or Spark can lower that.

• In Spark, every task in an executor runs its own scan, and each one sizes itself to all the machine's cores.
• A 4-core executor running 4 tasks therefore decodes 4 × 16 = 64 splits at once.
• Each split holds the decoded chunks of every column it overlaps.
• On wide, nested files this means GiBs of native memory per executor, and executors get OOM-killed (Wide nested scans hold GiBs of native memory: tiny misaligned splits each decode whole column chunks #11123).

A full scan of a 180 MB list-layout file, measuring live native bytes:

On this file, fewer splits in flight costs no time and cuts memory by two thirds.

Proposed solution

A per-scan limit on how many splits are decoded at once:

• ScanRequest::split_concurrency: Option<NonZeroUsize>, used by both layout data sources;
• ScanOptions.splitConcurrency() in JNI;
• a vortex.splitConcurrency Spark read option.

Additional context

This reduces the impact of #11123 but doesn't fix it. The root cause there is scans splitting wide nested files into tiny ranges that each decode whole column chunks.

I have a PR ready.