feat: add merge strategy option to merge command and UI

[nelson870708]

As I mentioned in #1912, I added merge strategy option to merge UI.

[love-linger]

I'm sorry. I've revert this PR manually because the octopus is not suitable for merging two heads.

[love-linger]

And for two-heads-merging, the default ort merge-strategy is considered more predictable and consistent between your local machine and GitHub.

I think for two-heads-merging, you may need --strategy-option=ours|theirs|.. with the default ort merge-strategy instead of choosing another merge-strategy

[nelson870708]

Thanks for the clarification!

Regarding octopus:
I understand that it’s primarily intended for merging three or more heads, but technically it can still handle two heads without issues. My original intention was simply to reuse the existing multi-head merge code path to keep the implementation simpler and reduce future maintenance cost. If using octopus for two-head merges is not appropriate for the project, I’m totally fine removing that part.

About merge strategy vs strategy-option:
They are related but conceptually different. A quick example:

• Merge strategy (--strategy=) chooses the merge algorithm:

  git merge --strategy=recursive git merge --strategy=ort git merge --strategy=ours 

• Merge strategy options (--strategy-option=) modify the behavior within a chosen strategy.
  For example:

  git merge --strategy=ort --strategy-option=ours 

  In this case, the strategy is still ort, not ours—the option only tells ort how to resolve conflicts.
  This distinction is subtle but important in real workflows.

A concrete example from my workflow as a research engineer:
I often create an experimental branch for testing different algorithms or configurations. After an experiment is finished, I want to merge it back into the develop branch without letting the experimental changes overwrite anything in develop—but I also don’t want to lose the experimental commits, since I may need to revisit them later to check certain configurations.
Using --strategy=ours perfectly solves this scenario: it lets me merge the branch while keeping develop untouched and still preserving the experimental commit history.

The main motivation of the PR is to make the single-branch merge flow consistent with the multi-branch flow—so users can choose the appropriate strategy or strategy-options (like always keeping the current branch) even when merging just one branch.

If you feel a different approach fits the project better, I’m happy to adjust the PR accordingly or help refine the implementation.

Thanks again for the feedback and for reviewing the PR!