[BUG]: README: Broken emoji links in Contributors section (missing anchors)

[Chealer]

📝 Describe the bug

The Contributors section of the README has lots of links which bring to pages which―while they are not errors―do not show the expected information on contributions. It's not fully broken, but highly so.

For example:

1. Clicking the 💬 link under Danny Garside just changes the URL to https://github.com/all-contributors/allcontributors.org/blob/main/README.md#question-da5nsy, which appears to be a missing anchor. Similarly, clicking the next link (📆) just changes the URL to https://github.com/all-contributors/allcontributors.org/blob/main/README.md#projectManagement-da5nsy, another missing anchor. And the same for 🤔under Rebecca Ringuette or Felix Schneider. And the same for 🚇under Jim Madge or Felix Schneider. Or 🖋 under JohnnySD.
2. Clicking the 🐛 link under Anne Stellingwerf brings to https://github.com/all-contributors/allcontributors.org/issues?q=author%3Aastellingwerf, which shows no content.
3. Clicking the 💻 link under Felipe Moreno brings to https://github.com/all-contributors/allcontributors.org/commits?author=flpm, which shows no content.

Making matters worse, each time #1 is triggered, Firefox 149 (2 installs on 2 tested) does not bring the viewport back to where it was, so the user may close the tab and lose where they were if he doesn't realize he's basically already there.

License

👣 Steps to Reproduce

Not a software bug to my knowledge

🎯 Expected behavior

See above

💡 Additional context

No response

🤝 Participation

• I am willing to submit a pull request for this issue.

[JimMadge]

These anchors are generated by the CLI, they are placeholder links for contribution types without a link defined.

I've found them to be confusing before, and can trigger many errors from a link checker.
I would support having no link in these cases. That would be a breaking change though, I'm not sure if anyone is using this feature. We could add a configuration option to enable this which defaults to false. @lwasser @jdalrymple @JoshuaKGoldberg what do you think?

[Chealer]

Thanks @JimMadge

I believe the code Jim points to is indeed involved in issue #1. I don't know the project enough to judge, but that function is visibly used as a fallback. If there is nothing to point to for these types, I sure support not having broken links. Making whatever that is opt-in does seem like the right approach.
It would clarify to refactor that file a bit (at least 1 or 2 comments wouldn't hurt).