git: cherry-pick, rebase and pull --rebase

`docs/13_git_interface.md` lists cherry-pick and revert as "out of scope until a concrete caller needs them." Here is one.

### Use case

A long-lived checkout on a shared branch, with local commits that are not pushed yet, while other clients push to the same branch. Catching up with `merge` or `pull` adds a merge commit every time and makes the history non-linear. What a developer does here is `git pull --rebase`: the local commits exist nowhere else, so replaying them on top of the upstream rewrites nothing shared, and the history stays linear.

### Ask

1. `cherryPick` on the client, and `git cherry-pick ` in the shell. isomorphic-git already ships `cherryPick` (a three-way merge against the commit's own parent, applied to the working tree), so this is a wrapper in the shape of `merge`.
2. `rebase` on the client, with `git rebase ` and `git pull --rebase` in the shell: reset the branch to the upstream and cherry-pick `upstream..HEAD` oldest first, stopping on a conflict with the paths reported as `merge` reports them. `--autostash` would be welcome, since `stash` is already there.
3. `revert`, if you want to close the set.

### Related

isomorphic-git's `merge` writes the merged tree and the commit and moves the branch, but on a clean merge it does not update the working directory; only `pull` runs a checkout afterwards. Through the client, a clean `merge` therefore leaves every file it changed reading as a local modification back to the old content. Worth a line in the docs.

### Environment

`@cloudflare/computer` 0.3.0 (pkg.pr.new build `9184be3`), isomorphic-git 1.38, Workers runtime.