refactor: display input partitions for RepartitionExec

[crepererum]

Which issue does this PR close?

Closes #4964.

Rationale for this change

With the recent changes in query planning, RepartitionExec nodes are inserted a bit more "black magic" style. When looking at a EXPLAIN output like this one RepartitionExec: partitioning=RoundRobinBatch(4) it would be nice if it would be easier to judge how the data is reshaped if the number of input partitions would also be printed.

What changes are included in this PR?

Add input_partitions=... to RepartitionExec representation.

Are these changes tested?

Existing tests.

Are there any user-facing changes?

Slightly different EXPLAIN plans.

[mingmwang]

LGTM

[ursabot]

Benchmark runs are scheduled for baseline = 96cf046 and contender = 19f6f19. 19f6f19 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