Add advice about submitting potentially hard-to-review PRs

[jieyouxu]

Prior discussion: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Expert.20map.20and.20suitable.20reviewer.20maps.3F/near/456305821.

Some context (partial summary of the prior discussion): I've noticed that we have had quite a few cases of the spin-the-bottle or pass-the-hot-potato review assignment reroll game (at least for the compiler reviewers) because some PRs might be very hard to review (due to being massive/complex/cross-cutting/highly domain specific etc.).

So in this PR, we add some advice for contributors about making potentially hard-to-review PRs (those that are large, complex, cross-cutting and/or highly domain-specific) to:

• Talk with t-compiler before submitting a very difficult to review PR
• Work with t-compiler to break down a large unreviewable PR into smaller, more reviewable PRs

cc @wesleywiser and @davidtwco compiler team leads for a vibe check and wording feedback, and if we want to make this advice at all.

[jieyouxu]

(Seems like PR CI has a bunch of pre-existing link check errors)

[apiraino]

Suggestion (but not important): "In this case, a bot will automatically ping relevant groups based on the code that the patch is touching."

(or something along this line)

[jieyouxu]

Added basic info about triagebot notifying relevant teams and people who registered specific alerts. I was almost going to write a sentence to the effect of "if you see a massive list of pinged people, the PR is probably too large" but that's already after a person spent a ton of time and effort, so I decided against that.

[apiraino]

I really like the wording here! If it's not explicited elsewhere, it's an important addition to our developer documentation - it suggests common good practices when collaborating on / contributing to a FOSS project)

[compiler-errors]

💞

[jieyouxu]

(Contains no changes, just rebased to overcome CI failure)