Add an issue template for future-incompatible lints

[ehuss]

This adds a GitHub issue template for future-incompatible lints. Most of the existing tracking issues have been using different formats with different information, and I think it would be helpful to make them a little more consistent and to ensure that sufficient information is provided.

Some comments on my choices:

• Added a dedicated section to describe why the change is being made. Many existing issues already have this, so let's standardize on it.
• Have a section with a very clear example. Almost all of the existing issues have this in one form or another.
• Added a "Recommendations" section, since this is something I see missing in several of the existing issues, and this is really important information IMHO.
• I reworded the "When" section. The existing template mentioned that these get reviewed every 6 weeks which my understanding is not true. That's also not very helpful information to the user, since it doesn't really answer the question. I'm not sure this section will actually be useful since I suspect most of the time we don't know when it will change (there have been a few exceptions).
• Clearly show the expected progression steps. Several issues already have this.
• Added implementation history, which is useful for linking PRs. (IDK, this could get merged with "Steps".)

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[jieyouxu]

Discussion: usually other tracking issues avoid encouraging detailed discussions on the tracking issue because it quickly becomes impossible to manage and usually there's no one around to actively summarize (esp. when it starts to collapse comments and backlinks extending the page height). Maybe instead have a section like "### Discussions and concerns" where dedicated issues for specific topics are backlinked to this main tracking issue?

[ehuss]

Yea, there are tradeoffs here. To be clear, this is from the RFC.

I agree that regular tracking issues are not well suited for discussion. However, I think a large part of these FCW issues is to solicit input from users. I can appreciate having a relatively lightweight means for people to leave comments about their concerns or questions. Unlike regular tracking issues, I suspect users won't be subscribing to the issue to receive updates since I doubt anyone will be looking forward to them closing (they aren't introducing new features people are excited about). And thus I'm not too concerned about it being spammy. I think if the issue does a good job of explaining the FCW and what is happening and why, then there should be fewer reasons for people to ask questions.

But if the team wants to change the process, I can update the text.

[jieyouxu]

I think this is fine. If we find that it becomes too spammy in practice, we can always:

• Change this template
• Lock the original tracking issue, and explicitly fork off separate discussion issues.

[ehuss]

I pushed an update, I realized I can now edit the rustc-dev-guide at the same time.