Introduce option to follow renames across merge commit boundaries

Commits that touch a specific file can view view by providing a pathspec to the specific file in question. Example: git log -- foo will show all commits that touch file foo. If the file was renamed at some point in its history, users may also be interested in seeing commits for this file prior to the rename. This can be accomplished by using the --follow option. Example: git log --follow -- foo may show additional commits in the history if the file was renamed at some point. One limitation here is that by default the --follow option is unable to check merge commits. This means in there is an "evil" merge that adds/renames the file in question, rename following breaks.

The root of the problem here is that rename detection requires the Git diff machinery and this machinery does not compute diffs for merge commits by default. We can force Git to generate merge commit diffs by using one of the --diff-merges formats, but there are downsides to using this approach discussed in gitlab#421655 (comment 2931485646).

We should explore adding an option like --follow-with-merges which computes pairwise diffs for merge commits against each of the parents, but unifies the log output so the merge commit is only shown once in the output. Not that this option only makes sense if no diff output is expected to be displayed.