FR: manually track moves and copies

[Zoybean]

Is your feature request related to a problem? Please describe.
I would like to be able to manually track a file move or copy, and have changes to the history of the source file affect the state of the destination file(s), regardless of any similarity or lack of similarity between the source and destination files.

Describe the solution you'd like
firstly, I'm writing these as subcommands of a jj file command, where the current jj files could sit as a new jj file ls. I don't care too much about what it is called in the end, but I think it would be useful to separate the file-oriented commands from the repo-oriented commands, hence jj file.

• jj file mv $source $dest: move file $source to $dest, and maintain the history (i.e. don't track it as a file deletion and a file addition, but as a name change)
• jj file mv --track $source $dest: retroactively track a file move, without actually moving anything. I.e. for a deleted file $source and added file $dest, treat it as if $source was renamed to $dest (i.e. mv $source $dest; jj file mv --track $source $dest would be the same as jj file mv $source $dest)
• jj file cp $source $dest: copy file $source to $dest, and copy the change history (if that's possible)
• jj file cp --track $source $dest: retroactively track a file copy (i.e. cp $source $dest; jj file cp --track $source $dest would be the same as jj file cp $source $dest)

Describe alternatives you've considered
An alternative is not to track copies or moves at all. I understand that move tracking is a desired feature, but I do not know if copy tracking is possible (in jj), or if so, if it is practical, to implement in jj.

Additional context
Similar to #2012, however it is specific to conflict resolution, whereas this is more general.
Related to #47, however this is independent of any file-similarity heuristics.
This is informed by me learning about hg mv and hg cp, only just today, however I am otherwise unfamiliar with hg, so I may have misunderstood these hg commands.

[joyously]

If you look at the Wikipedia VCS page, you'll see that most VCS have a command for move/mv and some have a command for copy/cp. (Breezy is the fork of Bazaar but it's not on there, and it has both.)

[arxanas]

It's somewhat tangential, but I like the idea of a jj file command. Also —

• It's best to not use the Unix names for commands/functions (except perhaps as aliases), as they're not self-explanatory.
• A jj file subcommand would also be a nice place to put what is currently jj cat (and perhaps rename it to jj file print or similar).

[martinvonz]

Sorry I forgot to reply earlier. The plan, IMO, is to let the commit backend decide whether renames are tracked like in Mercurial or detected like in Git. We might have a function like get_copies(source: &Commit, target: &Commit) and it would be up to the backend to decide where to get the information from and whether to calculate it on the fly. We would have commands for marking a file as copied/renamed and it would be up to the backend to decide whether to record that information or to just discard it. The Git backend would discard it.

[torquestomp]

I've started work on a hypothetical API [change] to power this feature, draft PR here: #3510. RFC on direction before I go any further

I'm hopeful we can do this in a way that:

• Integrates cleanly and performantly with Git
• Allows custom backends with explicit copy tracking to function performantly
• Handles the Mercurial amend problem (In Mercurial, if you create file A in a commit, then rename A->B and squash the rename, the rename info has nowhere to live so child commits don't get it on rebase)