commit-graph: change in "best" merge-base when ambiguous

Hello all,

While working on the commit-graph feature, I made a test commit that sets core.commitGraph and gc.commitGraph to true by default AND runs 'git commit-graph write --reachable' after each 'git commit' command. This helped me find instances in the test suite where the commit-graph feature changes existing functionality. Most of these were in regards to grafts, replace-objects, and shallow-clones (as expected) or when trying to find a corrupt or hidden commit (the commit-graph hides this corrupt/missing data). However, there was one interesting case that I'd like to mention on-list.

In t6024-recursive-merge.sh, we have the following commit structure:

     # 1 - A - D - F
     #   \   X   /
     #     B   X
     #       X   \
     # 2 - C - E - G

When merging F to G, there are two "best" merge-bases, A and C. With core.commitGraph=false, 'git merge-base F G' returns A, while it returns C when core.commitGraph=true. This is due to the new walk order when using generation numbers, although I have not dug deep into the code to point out exactly where the choice between A and C is made. Likely it's just whatever order they are inserted into a list.

In the Discussion section of the `git merge-base` docs [1], we have the following:

     When the history involves criss-cross merges, there can be more 
than one best common ancestor for two commits. For example, with this 
topology:

     ---1---o---A
         \ /
          X
         / \
     ---2---o---o---B

     both 1 and 2 are merge-bases of A and B. Neither one is better than 
the other (both are best merge bases). When the --all option is not 
given,     it is unspecified which best one is output.

This means our official documentation mentions that we do not have a concrete way to differentiate between these choices. This makes me think that this change in behavior is not a bug, but it _is_ a change in behavior. It's worth mentioning, but I don't think there is any value in making sure `git merge-base` returns the same output.

Does anyone disagree? Is this something we should solidify so we always have a "definitive" merge-base?

The biggest reason I think we should avoid sticking to the existing behavior is that the current behavior depends on the walk order. That means we would not be able to concretely define a tie-breaker without changing the existing behavior anyway.

Thanks, -Stolee

[1] https://git-scm.com/docs/git-merge-base#_discussion