Add label clone command - #5452

@samcoe if you take #5451 I'll probably refactor into a single package to reuse many of the same private funcs much like the codespaces command does. Could use list and then create in a loop which will automatically take advantage of the --force switch support I added.

@heaths I think #5451 is a good addition and it makes sense to extract out common functionality into a shared or common file which we do in a couple different commands 👍

I could do that as well. The funcs would have to be public, of course, but all that is under internal/ anyway.

@samcoe wanted to get your preliminary feedback on this. Once I incorporate any feedback I will add tests and convert this to a real PR.

Some thoughts for future improvements that we might want to address after testing out the command:

1. Parallelizing the creation of labels. Even on a small amount of labels (40) the command can take seconds to run.
2. Adding in a confirmation prompt, generally we reserve this for destructive actions, but I can see how it would be valuable since it can be super tedious to undo (deleting) numerous labels.

I don't think either needs to be addressed right away just food for thought.

I will get this merged before the next release.

@samcoe, anything holding it up now? I have another PR that is based on this work to improve the label list command and add the label remove command, but didn't want to make it a full PR until I can rebase onto trunk from where it diverged this with one. IMO, making the label command complete by next release would be ideal.

Parallelizing the creation of labels. Even on a small amount of labels (40) the command can take seconds to run.

I've never actually tested this nor seen it in docs, but is there a simultaneous connection limit per client ID for GitHub APIs? And, if so, is it different for REST vs. GraphQL? This could significantly impact the design. Could either go with a fixed-sized goroutine pool or just span goroutines as needed e.g. per label creation/update. Normally I'd lean toward the former.

Rebased on trunk to resolve merge conflicts.

@samcoe here the other one now that I've rebased it onto trunk: #5503

Documented in https://cli.github.com/manual/gh_label_clone
Very useful ❣️ Thanks a lot.

It helps on community/community#15300

🎁 Thanks a lot for the feature 🙏
Here is my feedback : https://dev.to/adriens/github-cli-v290-is-out-clone-labels-feature-5452-is-here-3odk