cli: change the default revsets for push to be based on trunk()

[rslabbert]

As with #2088, I'm not wedded to this, but it seems like a valuable change for my workflow at least and matches git-branchless submit.

Builds on the trunk alias from #2088. The benefits of this over the previous default in my opinion is:

1. It captures the entire stack range instead of just up to @, meaning you can run it from inside a stack; and
2. It's built on trunk()..@, so if the trunk branch was accidentally modified, the default push won't include it.

Note: Once trunk() is made into a built-in function, we can create a stack() function that resolves to (trunk()..@):: which should be a bit cleaner than the current approach.

[ilyagr]

I'm not sure whether this is always an improvement.

The situation this is meant for, as far as I understand, is if a descendant of @ or of @- has branches on it. Currently, jj git push wouldn't push those, which may or may not be intuitive.

One argument for the current behavior is that jj co <some-rev>; jj git push allows for a somewhat surgical pushing, if the work on the descendants is too incomplete to share.

Another possible problem with the approach of this PR is if a tree has a huge side branch (* represent commits, the root of the tree is on the left):

-----*------------------------* (trunk)
      \
       ----*---*---*----*------* @
            \
             --*--*----* (other stuff)
                \  \
                 *  *

With this PR, jj git push would push all the branches of (other stuff) as well. I'm not sure how common such a situation is, but it feels mildly worrying.

OTOH, I might not be the best person to judge this since I almost always use jj git push --all.

[ilyagr]

The & branches() seems to be unnecessary because of how jj git push -r is defined.

[ilyagr]

OTOH, an argument for something like this is that then the default "push"-set will match the default log revset.

[rslabbert]

Tabling this until immutable() is in place and maybe we have drafts()/stack(x).

Either way, I think a good approach would be to ensure that the default log, push, and rebase are all in sync. Especially if we want to draw a distinction between rebase vs merge workflows?

For example, if we're in rebase/stack world, given a stack with 2 commits on main if this is the default log:

@ commit-2 push-2*
|
◉ commit-1 push-1*
|
◉ commit-0 main

I suspect we'd want the default push to be push-1 and push-2 and the default rebase destination to be main.