Create "meta" "good first issues" to make sure we always have actual "good first issues" available

[kbeyls]

At the 2024 US LLVM developer's meeting round table on office hours, we observed that when looking with newcomers for an appropriate new first issue, many of the issues labeled that way are actually not very good "good first issues".

Most such issues require too much deep expertise to get started, and the learning curve before becoming productive is too steep.

We thought that rather than trying to maintaining a fully curated list of good first issues, it might be more effective to also have a few "meta" issues that document how to find issues yourself that are probably good beginner issues. We thought the following might be good sources for people to find good first issues themselves:

• Fixing warnings produced by static analyzers with low false positive rates. Maybe github runs static analyzers. If so, that would be an easy source for newcomers to find things that need fixing?
• Writing tests to increase code coverage could also be a good source for good beginner issues. How could newcomers prioritize which areas with low code coverage are most impactful to focus on?
• (Kristof after the round table finds that there is a community.o issue already for "Encourage newcomers to create PRs with updated documentatino when it's missing for them) Encourage newcomers to create PRs with updated documentation when it's missing for them #13

We thought that it would be good to make "meta" "good first issues" for these and similar sources of good first issues, and make them sticky at the top of the
good first issue list, so that they are easily found.
We could/should add links to office hours hosts in these sticky issues and/or add pointers to other available mentors.