feat: add split command

[claytonrcarter]

This adds a git split command to extract changes from commits. This mostly addresses #180, except for the -i/--interactive part. The split and rebase happens in-memory, so it should be fast. The command signature is

git [branchless] split <revset> <file> [<file>...]

• <revset> must resolve to a single commit (or just be a single commit, or @, etc)
• if only one file is given, then the file name is used in the extracted commit message
• if 2+ files are split out, then <n> files is used in the extracted commit message
• in either case, a brief insert/delete summary is also used, eg (+2/-5)
  • eg temp(split): lib.rs (+5) or temp(split): 3 files (+3/-3)

Implemented flags

These alter how the split/rebase happens:

• default (no flags) is "insert after": extracted changes are inserted into commit graph as a child of the target commit
  • any children of the target commit are rebased onto the extracted commit
  • eg A - B - C → A - B' - b' - C
• --detach: similar to above, but
  • children of the target commit are rebased onto the newly split target commit, not onto the extracted commit
  • eg A - B - C → A - B' - C and B' - b
  • that is: b and C are now both children of B'
• --discard: similar to --detach, but after extracting the changes, they are simply discarded
  • eg A - B - C → A - B' - C
• --before: the extracted changes are inserted as a parent of the newly split target commit
  • children of the target commit are rebased onto the newly split target commit
  • eg A - B - C → A - b - B' - C
• with --detach and --discard, rebase conflicts are possible, and are intended to be resolved in the same way are for git move conflicts

Status

This is "works for me" and has been stable and useful over months of personal testing. That said, the code is mostly OK, but there are still a few FIXME/TODOs to resolve, and I'm certain that the code could be more idiomatic or branchless
in general. I have written a bunch of tests, but it's possible that I have overlooked some edges.

Any and all feedback is welcome. I'm happy with this as is, but I'm looking forward to some review helping me be really proud of it. =)

Specific areas needing feedback and review

• The temporary commit messages. Style, format, etc. The code that generates them feels sort of complicated; maybe it's not pulling its weight, and we should use a simpler or more familiar option?
• The structure and flow of the business logic still confuses me a bit, and I suspect I'm overlooking some simplifications. For example, the variable names used for the new commits (extracted_commit and remainder_commit) feel good, but they actually mean the opposite if the --before flag is passed. 🤷 I've commented this to explain, but I'm hoping someone else will have some suggestions.

[claytonrcarter]

I pushed a fix for an issue that I had noticed for a while but couldn't reproduce: using split --discard on the current commit when the current commit was a checked out branch would leave the discarded changes in the index, making them look like they had been staged. My fix is to reset the index to the state of the newly split commit. That passes tests, but it's not clear to me how it will interact w/ something like the working copy snapshots. I think (hope?) those are applied later, but I'll play with this some more to see.