doc, config for nvim.difftool (built-in to neovim) as a diff-editor merge-tool

[DirectXMan12]

this notes/adds built-in config for the new(ish) builtin neovim support for dirdiffs, which makes neovim a relatively nice jj merge tool (nicer than vimdiff, easier to set up than the mentioned plugins since it ships in neovim ootb).

i've added 2 commits here -- a minimal "here's a link to the wiki" and a more maximal "here's an entry in the built-in config + a note in the docs". wasn't sure which was more preferable.

Checklist

If applicable:

• I have updated CHANGELOG.md
• I have updated the documentation (README.md, docs/, demos/)
• I have updated the config schema (cli/src/config-schema.json) (n/a)
• I have added/updated tests to cover my changes (n/a)
• I fully understand the code that I am submitting (what it does,
  how it works, how it's organized), including any code drafted by an LLM.
• For any prose generated by an LLM, I have proof-read and copy-edited with
  an eye towards deleting anything that is irrelevant, clarifying anything
  that is confusing, and adding details that are relevant. This includes,
  for example, commit descriptions, PR descriptions, and code comments.
  (n/a, this comes 100% from wetware ;-))

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[github-actions]

The following commits do not follow our format for subject lines:

• 19a75da: [docs] nvim 0.12.0 nvim.difftool instructions are in the wiki
• 0f7d0d0: ship a config for nvim 0.12.0's difftool as a merge-tool

Commits should have a subject line following the format <topic>: <description>. Please review the commit guidelines for more information.

All commits are now correctly formatted. Thank you for your contribution!

[josephlou5]

Please fix tests. Looks like test_completion::test_merge_tools is failing.

[DirectXMan12]

ok, tests fixed, reworded description slightly to clarify that this is a diff-edit merge-tool, and not a 3-way-diff merge-tool ¹.

in theory we could add a unified "neovim" or "nvim" entry that was nvim.difftool for edit, and vimdiff for merge. i can do that if you want, but it's not currently how i use stuff in my config, so i didn't think to initially do it.

Footnotes

1. i must've been a bit tired yesterday when i finally submitted this patch -- i swear i've read that config.md section like 30 times but every time i glazed over the fact that that list was just 3-way merge-tools, and not also diff tools. sorry bout that ↩

[DirectXMan12]

in theory we could add a unified "neovim" or "nvim" entry that was nvim.difftool for edit, and vimdiff for merge. i can do that if you want, but it's not currently how i use stuff in my config, so i didn't think to initially do it.

actually, now that i think about this more, i think this probably feels like a nicer experience for users. just being able to do --tool nvim seems nicer than needing to remember vimdiff vs nvim-difftool.

lemme test that real quick and i'll push the changes

[DirectXMan12]

ok, ci looks green on those new changes, should be good for another review round

[josephlou5]

I think I'd personally prefer a commit that adds the tool directly instead of just in the documentation (so your second commit), but I'm not a maintainer so just providing my opinion (no changes needed).

(I also don't use Neovim, so this is just from the perspective of "if we can make it easier for users, might as well make it easier for users" ¯\⎽(ツ)⎽/¯)

[josephlou5]

(Also, I won't give approval (but again, not a maintainer) because for now there are 2 commits doing different things, so this PR can't be merged as-is.)

[DirectXMan12]

cool, I'm happy to drop the first commit if others feel the same way, figured I'd just offer the option

[DirectXMan12]

(I personally prefer the second commit too, so seems good to me, but I'll wait for a maintainer to weight in)

[PhilipMetzger]

nit: I think all of this can be a single commit.