FR: Use `-p`/`--path` everywhere for path arguments

[arxanas]

Is your feature request related to a problem? Please describe.

I am constantly running jj log <rev> and then it silently doesn't work/hangs because jj is busy trying to find paths that match <rev> in the commit history. This is a common footgun and we've implemented a few checks to try to detect path arguments that look like revset arguments, but it continues to happen.

There's not a fundamental reason why paths are "more important" than revsets for most commands, so we should stop treating them as a "default" kind of argument for most (if not all) commands.

I believe a lot of the path arguments are positional primarily for historical reasons (namely, Git and Mercurial did it that way).

Describe the solution you'd like

• In all cases, where positional path arguments are currently accepted, arguments of the form -p/--path should also be accepted.
• In cases where positional path arguments are currently accepted, we should probably deprecate that and require the user to specify with them with -p/--path.

Describe alternatives you've considered

• Note that revsets also support querying commits that touch paths, which is a related feature, but not entirely the same. The details about which path was specifically selected carries useful semantic information.
  • For example, git log --patch -- <path> will limit the shown diff to only the parts touching the provided paths. I'm not sure if jj does anything similar at present.
• One problem with requiring -p is that you can't use the shell's globbing functionality.
  • In some cases, you can write --path={foo,bar,baz} to accomplish a similar workflow (as it will then expand to --path=foo --path=bar --path=baz).
  • I think a --paths (plural) argument that accepts any number of subsequent arguments is justifiable.

Additional context N/A

[yuja]

For reference, there's a previous discussion in https://github.com/martinvonz/jj/issues/2554