FR: Add "manual rename" command

[chooglen]

Before we get full rename detection (#47), we could implement a "manual rename" that addresses the case where one side makes a change to a file and another renames it.

We could do this by first showing the sides in the conflict, say left, right, base, where left changes file src/bla, and right renames src -> cli/src. A manual rename like jj rename --side=left src/bla cli/src/bla would take the change from left and apply it on cli/src/bla instead of src/bla.

How I envision this working in terms of conflicts is that start with the following conflict expressions:

• src/bla: L + R - B (where R is the 'missing' file)
• cli/src/bla: B

Then we move the base -> left terms to cli/src/bla (maybe we'd also prompt the user to provide base?):

• src/bla: R (where R is the 'missing' file, so the file is deleted)
• cli/src/bla: L - B + B = L

Which also has a well-defined result even in the case where base -> left doesn't apply cleanly onto the renamed file. Perhaps that has some practical use for moving changes across files outside of a rename, but I haven't quite thought that through.

[scott2000]

I wonder if it might be nice to have a subcommand for dealing with the conflict trees. For instance:

jj conflict mv <FILE> <DEST>
jj conflict cp <FILE> <DEST>
jj conflict rm <FILE>

Which would by default perform the operation on all conflict trees in the working-copy commit which contain <FILE> but not <DEST>. The command could also operate on a specific tree using --base <N> to specify a "remove" tree and --side <N> to specify an "add" tree (using terminology from #3459).

For instance, if the base tree contains a.txt, then side 1 modifies a.txt and side 2 renames a.txt to b.txt, then the command jj conflict mv a.txt b.txt would resolve the conflict by applying the rename to both the base and side 1 since they contain a.txt.