SQL planning benchmarks for very wide tables

[alamb]

Which issue does this PR close?

Related to `

Add test case for (even larger) tables:

To run:

cargo bench --bench sql_planner

Rationale for this change

There is substantial overhead even without any sophistication. Let's get a microbenchmark up for that

What changes are included in this PR?

1. Add a benchmark based on code from @zeodtr in Optimizer is slow: Avoid too many string cloning in the optimizer #5157
2. Update the planning code to be clearer about what it is doing

Are these changes tested?

Not really (they are benchmarking code)

Are there any user-facing changes?

No

Example output

[ursabot]

Benchmark runs are scheduled for baseline = 253550c and contender = 07ae738. 07ae738 is a master commit associated with this PR. Results will be available as each benchmark for each run completes.
Conbench compare runs links:
[Skipped ⚠️ Benchmarking of arrow-datafusion-commits is not supported on ec2-t3-xlarge-us-east-2] ec2-t3-xlarge-us-east-2
[Skipped ⚠️ Benchmarking of arrow-datafusion-commits is not supported on test-mac-arm] test-mac-arm
[Skipped ⚠️ Benchmarking of arrow-datafusion-commits is not supported on ursa-i9-9960x] ursa-i9-9960x
[Skipped ⚠️ Benchmarking of arrow-datafusion-commits is not supported on ursa-thinkcentre-m75q] ursa-thinkcentre-m75q
Buildkite builds:
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python, R. Runs only benchmarks with cloud = True
test-mac-arm: Supported benchmark langs: C++, Python, R
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java