Add feedstock renaming request

Periodically feedstocks need to be renamed

In fact this was discussed very early on in conda-forge development ( https://github.com/conda-forge/conda-forge.github.io/issues/179 ) as it was already spotted as a tricky case that we would like to smooth out (ideally with some automation)

There are a few cases where this happens...

1. The upstream library was renamed
2. It is later decided the name of the feedstock wasn't right (some examples below)
2.a. It has a `python-*` prefix when upstream doesn't and there is no risk of confusion
2.b. Its name overlaps with other related concepts/packages and needs qualification (like adding `python-` to `build`)
2.c. The name is otherwise confusing, misleading, or otherwise muddies the waters

Here are [a number of issues about renaming feedstocks]( https://github.com/search?q=org%3Aconda-forge+rename+feedstock&type=issues&p=5 )

The current approach in these cases is to archive the feedstock and add a new recipe with the new name to `staged-recipes`. For some cases this may make some sense. That said, it does add a lot of complexity when renaming a feedstock. It also opens the door for additional requests on the person doing the rename that are well outside the scope of renaming the library. Not to mention there are many manual pieces that still need to be handled after. For example...

1. Filing an issue to explain why the old feedstock is being sunset
2. Migrating issues from the old feedstock to the new one
3. Archiving the old feedstock
4. Adding a linter hint to transition to the new name
5. Adding a migrator to transition to the new name: https://github.com/conda-forge/conda-forge.github.io/issues/1894
6. ?

Having so manual steps covered like this leads to idiosyncratic differences, missed steps, and confusion

A better approach would be to add a rename request workflow to this repo

As this repo already has the logic needed to convert recipes at `staged-recipes`, it should be possible to reuse this in the renaming workflow. We could also handle [transferring open issues with the GitHub CLI]( https://cli.github.com/manual/gh_issue_transfer ) and [create an archive issue]( https://cli.github.com/manual/gh_issue_create ). Already we handle the archive workflow here so that could be reused ( and perhaps improved: https://github.com/conda-forge/admin-requests/issues/1324 ). We already are familiar with creating bot PRs to `conda-forge-pinning`. So we could use this to add a hint. It would also make sense to add a migrator

If there are other requirements I've missed, which only points out how much there is to do here, we could consider capturing those requirements in this workflow as well

If new requirements came up in the future, we would have a way to encode them in this request workflow and systemize them