Consistent no_prelude attribute

[Skgland]

Rebases and adjusts the work of the inactive pr #32025 for rust-lang/rfcs#501
with tracking issue #20561

From the original PR:

Adds the no_prelude attribute that stops automatic injecting of the standard prelude in a single module behind a feature gate.
Deprecates the existing no_implicit_prelude.

This version does not deprecate no_implicit_prelude as this appears to be the consent of the discussion of the original pr.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @oli-obk (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[oli-obk]

r? @alexcrichton since you reviewed the last PR

[bors]

☔ The latest upstream changes (presumably #80530) made this pull request unmergeable. Please resolve the merge conflicts.

[petrochenkov]

The PR is from 2016 and the RFC is from 2014, the whole idea should probably be revised before proceeding.

In recent years #[no_implicit_prelude] was mostly used in compiler tests and by people wanting to stress the compiler, it was also a source of problems during macro modularization and other name resolution changes.
I'd personally be more interested in removing #[no_implicit_prelude] than in adding one more similar attribute.

[bors]

☔ The latest upstream changes (presumably #80459) made this pull request unmergeable. Please resolve the merge conflicts.

[alexcrichton]

Er sorry I don't really remember the context of a PR I reviewed 5 (!) years ago at this point. I'm probably not the best reviewer for this. Would you be ok selecting a different reviewer?

r? @oli-obk

[bors]

☔ The latest upstream changes (presumably #80425) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #80867) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #80782) made this pull request unmergeable. Please resolve the merge conflicts.

[oli-obk]

The PR is from 2016 and the RFC is from 2014, the whole idea should probably be revised before proceeding.

In recent years #[no_implicit_prelude] was mostly used in compiler tests and by people wanting to stress the compiler, it was also a source of problems during macro modularization and other name resolution changes.
I'd personally be more interested in removing #[no_implicit_prelude] than in adding one more similar attribute.

I have no real knowledge of this area, but I agree that just the existance of an RFC does not motivate the change, and I'm not sure the original motivation still applies (considering that there was no activity on the tracking issue for years).

cc @Kimundi@Nemo157 how do you feel about abolishing this scheme entirely and coming up with something new that does not conflict with macro imports?

[bors]

☔ The latest upstream changes (presumably #81113) made this pull request unmergeable. Please resolve the merge conflicts.