make gh pr create behavior like gh repo fork

[leavesster]

this pr make gh pr create create origin remote not fork remote, and will rename old origin remote to upstream, so the gh pr create will have some behavior as gh repo fork.

The implementation in the code and the gh repo fork command are almost identical. I have read both sides of the code and find them good enough.
I think the best approach to unify these two command would be to use the code from the fork command, as it ensures consistent behavior. However, I am not sure if calling another command is a good practice. Alternatively, we could consider extracting a common function. But I am not very familiar with the overall architecture, so I am unsure where the common code should be placed.

Fixes #4627 and #7320

[samcoe]

@leavesster Appreciate the effort getting this work started. I left some inline code feedback on changes I would like to see. Please let me know if you have any questions regarding them.

[samcoe]

I do not think this logic is defensive enough against the variety of remote setups a user can have. I think we only want to rename the origin remote if it corresponds to the baseRepo for the PR being opened.

How I am envisioning this working:

1. Check to see if the baseRepo remote is named origin using ctx.RepoContext.RemoteForRepo(baseRepo)
2. If it is, then rename it to upstream and add the new fork as the origin remote
3. If it is not named origin then leave it alone, and add the new fork as the origin remote
4. If there is already an origin remote that is not the baseRepo then add the new fork as the fork remote as we previously we doing

How does that sound to you?

Lastly, since this logic is getting a bit complex I would like to see us output some messaging to the user telling them exactly what we are doing to their remotes so they are not surprised by the changes we are making to their local repo.

[leavesster]

I think it's fine, but considering the simplicity of the code implementation, I have made some modifications to the logic which still have the same result:

1. First, check if the origin remote exists.
2. If the origin remote not exists, then add the new fork as origin remote. Then everything is done.
3. If the origin exists, check if it is the baseRepo.(where I use ghrepo.IsSame to checke baseRepo and the origin Repo)
4. If origin is the baseRepo, rename it to upstream.
5. If origin is not the baseRepo, follow the previous behavior: name the fork remote as fork.

It is possible that the above logic does not account for a situation where the baseRepo repository is the origin and there is also an upstream remote.
My reference implementation is based on the git repo fork command because it also does not handle this logic. Therefore, I have not implemented it for now. If you think it is necessary, we can consider this scenario.

And I add two output message, one is rename origin to upstream when the exist baseRepo is 'origin', the other output is the forked repo's remote name.

[leavesster]

@samcoe code has been updated.

[samcoe]

@leavesster Thanks for the contribution and making the requested changes. I pushed a couple small commits to tweak the code to make it slightly less nested as well as making the output a bit more user friendly. This looks good to ship!