Add tokio 1.0 policies to contributing guide

[dekellum]

Motivation

The 1.0 roadmap of #2718 and the Announcing Tokio 1.0 blog post both contain details of release and versioning policy moving forward. As discussed on discord, its helpful to contributors to have all the policies in one place.

Solution

I've tried to consolidate these appropriately in the CONTRIBUTING.md guide, and I also have made few general cosmetic changes.

[Darksonn]

Thanks! I have some nit-picks below.

[dekellum]

@carllerche I have some related questions about what you meant in #2718, the blog post, and in the text as is re-used here:

LTS guarantees [...] 5 years of maintenance.

(1): Does this mean that Tokio Maintainer will "port" (in either direction), as matter of process, bug fixes to 1.0.z patch releases for 5 years? Or upon request/need?

(2): Or if that doesn't happen out of need sooner, would you accept PRs from user-contributors to do the same, at any time in the 5 year period (through 2025)? (For an old example, with less Semver constraints, see #1604.)

(3) Or, does the release of 1.1.0 somehow close out support on 1.0.z?

I don't think you meant (3), because of course if 1.1.0 has an MSRV increase or deprecation, then users are in a similar bind, right? Or at least, it would seem we users will want to reserve the right to do the work for (2), if we need to stay on an older minor release series for some period of time?

Perhaps the answer could be some kind of an addition FAQ section that could be added to the guide, in this PR or after?

[taiki-e]

The reason it is called E- is that the main Rust repo calls the same thing E-. As for why they call it that, no idea.

FYI: https://rustc-dev-guide.rust-lang.org/contributing.html#issue-triage

Green, E-prefixed labels explain the level of experience necessary to fix the issue.