refactor: move MergeRows planning into dedicated module

[andygrove]

Which issue does this PR close?

Part of #6979.

Rationale for this change

PhysicalPlanner::create_plan builds most operators inline, which makes planner.rs the most frequently edited file in the native code and a regular source of merge conflicts. #6979 proposes finishing the move onto OperatorRegistry, one operator family per PR. This is the first of five PRs for its first sub-task, which moves the largest create_plan arms.

What changes are included in this PR?

• Move the MergeRows arm of create_plan into a MergeRowsBuilder in a new planner/merge_rows.rs, along with merge_output_type_compatible, which only it uses.
• Add OperatorType::MergeRows and register the builder.

The moved code is unchanged apart from self becoming planner in the builder and rustfmt reflowing the dedented lines. git show --color-moved=zebra --color-moved-ws=allow-indentation-change marks almost all of the removed lines as moved.

How are these changes tested?

This moves code without changing behavior, so it relies on the existing tests:

• cargo fmt --all -- --check
• cargo clippy --color=never --all-targets --workspace -- -D warnings
• cargo test -p datafusion-comet --lib (874 passed, 5 ignored)
• ./mvnw test -Dtest=none -Dsuites="org.apache.comet.exec.CometMergeRowsSuite" with -Pspark-4.0, whose version of the suite runs the native MERGE tests (10 passed), and on the default Spark 4.1 profile (3 passed, 1 canceled because it needs Spark 4.2)

[andygrove]

Closing in favor of #7014, which has all five of these moves in a single PR.