Rationalize GitHub-vs-portal-based team join requests

[jeffwilcox]

Before GitHub implemented team join requests many years ago, this portal had the concept
of a team join request.

A key difference, and why we are still using the in-portal experience primarily, is that at scale,
with thousands of users, it's difficult to understand "who, what, why" on these sorts of requests.

The in-portal experience differs from GitHub: GitHub simply has a "join" button, which tells the
team maintainers to approve the request. The portal experience has a "justification" free-form
text box, to allow the requester to provide context. The approve and deny experience also
lets the person making the decision document why they made the decision, to inform the user.

Across over 100,000 requests we have had in many years, over 21,000 of the requests were
denied.

A majority of the requests are because people want to contribute to a repo, something they can
do just fine with a fork and pull request, for example.

So potential work here:

• Show GitHub-based team requests in the portal UI
• Consider dropping the context-based in-portal experience
• Consider keeping the separate approach, with metadata, on top of a native join experience on GitHub
• Other ideas

[github-actions]

This issue has been identified as stale because it has gone 30 days with no activity.
The issue will be closed in 10 days. If this is incorrect, simply comment on the issue, or remove the stale label.