cli rebase: do not allow -r --skip-empty to empty descendants

[ilyagr]

This follows up on @matts1 's #2609.

We still allow the -r commit to become empty. I would be more comfortable if
there was a test for that, but I haven't done that (yet?) and it seems pretty
safe. If that's a problem, I'm happy to forbid -r --skip-empty entirely,
since it is far less useful than -s --skip-empty or -b --skip-empty.

I think it is undesired to abandon emptied descendants. As far as descendants
of A are concerned, jj rebase -r A should be equivalent to jj abandon A,
and jj abandon does not remove emptied commits. It also doesn't seem very
useful to do that, since I think descendant commits of an abandoned (or moved
with -r) commit only become empty in pathological cases.

Additionally, if we did want -r to empty descendants of A, we'd have to add
thorough tests and possibly improve the algorithm. I want to refactor rebase -r and add features to it, and having to consider cases of commits becoming
abandoned makes everything harder.

For example, if we have

root -> A -> B -> C

and jj rebase -r A -d C empties commit B (or C), I do not know whether
the current algorithm will work correctly. It seems possible that it would, but
that depends on the fact that empty merge commits are not abandoned for
descendants. That seems dangerous to rely on without tests.

I hope (but can't promise) that in the near future, making DescendantRebaser
return more information should help make it possible to create such
functionality in a more robust way. I am likely to attempt this as part of
implementing -r --after.

[ilyagr]

(I briefly added a second commit to this, but now I think I should add a test to that, so I removed it again)

[martinvonz]

Makes sense