Add an extended prelude for the 2018 editions

[SimonSapin]

As proposed in #51418.

---

Update: Per discussion below this PR also needs to add a warning for 2015 edition code that would break with the new prelude. Help wanted: any ideas how to make that happen?

[rust-highfive]

r? @withoutboats

(rust_highfive has picked a reviewer for you, use r? to override)

[leodasvacas]

Yay more prelude. But how will the decision be made for proposed extensions such as: Debug, Display, HashMap, HashSet, FromIterator.

[killercup]

I'm not sure if we rustfix can easily fix errors like carllerche/h2#251 to migrate us to the new prelude.

I think we can, in theory, write lint to the rust-2018-compatibility group that changes calls to methods that become ambiguous to their fully qualified form. But I'd rather hear from @Manishearth who has way more experience with this and can better judge the horrors edge cases we might run into.

[SimonSapin]

@leodasvacas I think that a decision for each of these needs to be made on a case-by-case basis, and not necessarily in this PR.

@killercup I just checked https://rust-lang.github.io/rfcs/2052-epochs.html#a-broad-policy-on-epoch-changes and having rustfix automate the transition would be nice to have but per the RFC it is a requirement that code that would break warns in the previous edition. Unfortunately I don’t know how to go about implementing that warning…

[Manishearth]

Lint feels a bit tricky to handle. Unsure what edge cases exist, though, so it might not be that tricky.

[estebank]

Just noticed this terrible suggestion. std::prelude::v1 is not an enum!

[pietroalbini]

Ping from triage! What's the status on this?

[SimonSapin]

This is blocked on additional implementation work (a warning on 2015-edition code that would break in the 2018 edition) that I don’t know how to do… or deciding an exception for this “hard requirement” stated in the RFC.

[SimonSapin]

Closing for now to make triage easier. This is still tracked at #51418.