Improve the purpose/usability of rubocop-github

### The current purpose of github-rubocop

The current purpose of this Repository from the README:

> This repository provides recommended RuboCop configuration and additional Cops for use on GitHub open source and internal Ruby projects.

### What does that include?

I think that includes:

- A. Baseline rules (`config/default.yml`) for upstream rubocop, rubocop-rails, rubocop-performance, etc. that is a consistent starting place for GitHub-maintained projects. Individual projects/teams are empowered to customize them to their preference.
- B. GitHub-specific cops that are specific to "GitHub open source and internal Ruby projects". For example:
- Cops that correspond to specific internal APIs, or Github-specific monkeypatches/behavior on specific projects.
- Cops that are relevant to _all_ GitHub-managed projects (but not _any_ project anywhere)

### What doesn't that include?

I think that does not include:

- C. Cops that would be applicable to _all_ projects within _and outside of GitHub_.

### Why distinguish GitHub from Everyone?

I think we will benefit the broader community/ecosystem if we make Cops that are applicable to _all_ projects available without having to pull in Rules and Cops that are only narrowly applicable to us.

I think we also will benefit ourselves by sending a stronger signal that we believe those Cops are good for _everyone_ and invite community discussion and participation.

### Where will the Cops go instead?

I think this workflow matches how other upstream contributions are managed internally at GitHub:

1. Propose the change upstream in the core open source project, where they have maximal visibility and discussion/feedback.
2. Patch them provisionally into GitHub's project(s), for immediate benefit. That could include this repository, or the proposer's Ruby project.
3. ...if the proposal is accepted, remove our patch and pull the updated upstream
4. ...if the proposal is not accepted, we usually learn something about our proposal, and we then choose whether to maintain the patch ourselves, discard it, or identify a better open-source home for it.

### What is the current disposition of Cops?

I definitely think this is more a molehill than a a mountain. And I think making the disposition of cops exemplary will help model the outcome we want to see (👪=Everyone, 🐙=GitHub, 🚝=GitHub's Monolith, ❌=redundant/removable)

- 🐙 `insecure_hash_algorithm.rb`: 🐙 All-GitHub. FIPS compliance
- 👪 / ❌ `rails_application_record.rb`: Everyone (duplicate in [rubocop-rails](https://github.com/rubocop/rubocop-rails/blob/master/lib/rubocop/cop/rails/application_record.rb))
- 🚝 `rails_controller_render_action_symbol.rb`: GitHub Monolith (performance-related)
- 🚝 `rails_controller_render_literal.rb` GitHub Monolith (performance-related)
- 🚝 / 👪 `rails_controller_render_paths_exist.rb`: GitHub Monolith (performance-related) or Rubocop-Rails?
- 👪 `rails_controller_render_shorthand.rb`: Everyone (I think I’ve seen this in the community, but now can’t find it)
- 👪 / ❌ `rails_render_inline.rb`: Everyone (duplicate in [rubocop-rails](https://docs.rubocop.org/rubocop-rails/cops_rails.html#railsrenderinline))
- 🚝 `rails_render_object_collection.rb`: GitHub Monolith?
- 🚝 ` rails_view_render_literal.rb`: GitHub Monolith?
- 🚝 / 👪 `rails_view_render_paths_exist.rb`: GitHub Monolith? Or Rubocop-Rails.
- 🚝 `rails_view_render_shorthand.rb`: GitHub Monolith (performance-related)

That adds up to:

- 🐙 1 cop that’s relevant to all GitHub projects. Because of our Security requirements (though reasonably applicable to everyone)
- 🚝 5 cops that are only relevant to the Monolith. Mainly because of performance patches we’ve done to `render` that I don’t think are widely relevant (e.g. Rails flexible development vs GitHub disciplined performance)
- 🚝 / 👪: 2 cops I’m not sure if they’re relevant to everyone, I’m leaning towards Monolith.
- 👪: 6 cops that are relevant to everyone, mainly Accessibility
- ❌: 2 cops that have been upstreamed that we can remove

### The Proposal

- [x] Document/clarify in README how to self-triage proposed changes
- [x] Create an internal service catalog entry for better internal discovery and communications
- [ ] Namespace update the existing Cops so that their intended target is clearer, and/or move them to a different more appropriate project.
- [x] Remove redundant/removable cops
- [x] https://github.com/github/rubocop-github/pull/123

Start with the remaining unchecked proposal to namespace the existing cops or move them to a more appropriate project, using the README's triage categories and listed cop files as the scope. Review the completed README clarification and PR 123 first; done means the cops' intended targets are clear and redundant cops are removed or relocated as proposed.

由索引模型根据 Issue 内容生成。