docs: Replace some mentions of jj co with jj new.

Also move some sentences away from "check out" to "create a new revision ...",
even if it isn't the phrasing we want.

Fixes #3487

docs/branches.md

@@ -7,7 +7,7 @@ Branches are named pointers to revisions (just like they are in Git). You can
 move them without affecting the target revision's identity. Branches
 automatically move when revisions are rewritten (e.g. by `jj rebase`). You can
 pass a branch's name to commands that want a revision as argument. For example,
-`jj co main` will check out the revision pointed to by the "main" branch. Use
+`jj new main` will create a new revision on top of the "main" branch. Use
 `jj branch list` to list branches and `jj branch` to create, move, or delete
 branches. There is currently no concept of an active/current/checked-out branch.
 
@@ -159,7 +159,7 @@ include information about the conflicted branches (and instructions for how to
 mitigate it). `jj branch list` will have details. `jj log` will show the branch
 name with a question mark suffix (e.g. `main?`) on each of the conflicted
 branch's potential target revisions. Using the branch name to look up a revision
-will resolve to all potential targets. That means that `jj co main` will error
+will resolve to all potential targets. That means that `jj new main` will error
 out, complaining that the revset resolved to multiple revisions.
 
 Both local branches (e.g. `main`) and the remote branch (e.g. `main@origin`) can

docs/git-comparison.md

@@ -32,9 +32,9 @@ various use cases.
   branch', and new commits will automatically update the branch. This is
   necessary in Git because Git might otherwise lose track of the new commits.
   Jujutsu does not have a 'current branch'; instead, you update branches
-  manually. For example, if you check out a commit with a branch, new commits
-  are created on top of the branch, then you issue a later command to update the
-  branch.
+  manually. For example, if you start work on top of a commit with a branch,
+  new commits are created on top of the branch, then you issue a later command
+  to update the branch.
 * **Conflicts can be committed.** No commands fail because of merge conflicts.
   The conflicts are instead recorded in commits and you can resolve them later.
   [Details](conflicts.md).