FR: Implement jj git sync

[essiene]

This is done as part of #1039, focusing only on jj git sync which is has agreement on proceeding. Summary from conclusion thread in #1039 is below:

Summary:
Ideally jj sync should be a un-namespaced command (without a backend prefix) but this makes it difficult to determine which implementation to use. @martinvonz's suggestion in an internal chat and on Discord was to make the command forge specific, e.g jj git sync, jj gerrit sync or jj piper sync and then allow the unnamespaced sync command to wrap it. This means that for the most users, jj sync would be jj git sync. Another option is to make that a buiiltin alias for each backend.

While I was initially sceptical of the namespaced approach, I now think it is the right solution for this problem. The only issue I see, if we take the forge-specific approach, is that some layering issue may pop up. But if we implement something like jj submit or jj mail, a forge trait is needed anyway.

Originally posted by @PhilipMetzger in #1039 (comment)

[martinvonz]

I'm not sure we need this separate FR (but I don't really mind it either). Will there be anything left in #1039 once this one has been implemented?

[essiene]

I'm not sure we need this separate FR (but I don't really mind it either). Will there be anything left in #1039 once this one has been implemented?

I'm not sure if there will still be work left to define a platform support so that a future jj sync invokes the forge specific sync action, if it exists.

So I didn't want to kill off the conversation by closing that issue when jj git sync is done.

wdyt?

[martinvonz]

I personally don't think we should define a top-level, forge-independent jj sync, so I think that issue should be closed when this one is closed.

[essiene]

I personally don't think we should define a top-level, forge-independent jj sync, so I think that issue should be closed when this one is closed.

My bad. I misunderstood the conclusion of that thread. I'll just close this and assign the other to myself to not split the conversation history.

Thanks for clarifying.