This brings repositories.txt into sync with the production file @60ebae3ec0715c211682820354ebb0dfc3de2436. Many libraries
have been added via the old process, and a couple renamed, since the time this repository's file was generated.
UI element label text mentions intermingled with prose text in documentation can harm readability, especially when
skimming. For this reason, I think it is helpful to add formatting to clearly distinguish this text visually.
The previous wording was verbose and unclear, the result of copy/paste-based writing.
A backwards compatibility anchor tag is not needed in this case because this documentation has not yet been published,
meaning that there has been no opportunity for the creation of external links pointing to the old ID.
These anchor tags provide compatibility with links created before the heading text was changed (anchors are automatically
generated for headings). Placing them below the headings caused the page to be scrolled to below the headings when
visited via their links.
Previously, the submission list and the Library Manager index source list were both named "repositories.txt". I found having two files with similar content, but different purposes makes the already complex system unnecessarily difficult to understand.
Unlike the index source list, the submission list is solely a list of repositories, so its current "repositories.txt"
name is appropriate. The index source list contains other information unrelated to the library repository, so the
"repositories.txt" name is not so appropriate. Since the repository is named "library-registry", the filename
"registry.txt" makes sense.
If the PR is detected as something other than a submission, review is requested from a maintainer. It might be that the
PR was intended to be a submission and the submitter is able to resolve whatever caused it to be detected as otherwise
on their own. In this case, the automated system can handle things and review is no longer needed.
Review requests to the PR author are not allowed. Previously, there would be a spurious workflow failure for every PR
from a user in the `env.MAINTAINERS` array.
When a maintainer is submitting a PR, they can request reviews as needed, so the automated review request can simply be
skipped in this case.