expand/resolve: Turn #[derive] into a regular macro attribute

[petrochenkov]

This PR turns #[derive] into a regular attribute macro declared in libcore and defined in rustc_builtin_macros, like it was previously done with other "active" attributes in #62086, #62735 and other PRs.
This PR is also a continuation of #65252, #69870 and other PRs linked from them, which layed the ground for converting #[derive] specifically.

#[derive] still asks rustc_resolve to resolve paths inside derive(...), and rustc_expand gets those resolution results through some backdoor (which I'll try to address later), but otherwise #[derive] is treated as any other macro attributes, which simplifies the resolution-expansion infra pretty significantly.

The change has several observable effects on language and library.
Some of the language changes are feature-gated by feature(macro_attributes_in_derive_output).

Library

• derive is now available through standard library as {core,std}::prelude::v1::derive.

Language

• derive now goes through name resolution, so it can now be renamed - use derive as my_derive; #[my_derive(Debug)] struct S;.
• derive now goes through name resolution, so this resolution can fail in corner cases. Crater found one such regression, where import use foo as derive goes into a cycle with #[derive(Something)].
• [feature-gated] #[derive] is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following #[derive] (Attribute macros must be placed before derive attributes. reference#566). The following macro attributes become a part of the derive's input (this is not a change, non-macro attributes following #[derive] were treated in the same way previously).
• #[derive] is now expanded as any other attributes in left-to-right order. This means two derive attributes #[derive(Foo)] #[derive(Bar)] are now expanded separately rather than together. It doesn't generally make difference, except for esoteric cases. For example #[derive(Foo)] can now produce an import bringing Bar into scope, but previously both Foo and Bar were required to be resolved before expanding any of them.
• [feature-gated] #[derive()] (with empty list in parentheses) actually becomes useful. For historical reasons #[derive] fully configures its input, eagerly evaluating cfg everywhere in its target, for example on fields.
  Expansion infra doesn't do that for other attributes, but now when macro attributes attributes are allowed to be written after #[derive], it means that derive can fully configure items for them.

  #[derive()]
  #[my_attr]
  struct S {
  	#[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]`
  	field: u8
  }

• #[derive] on some non-item targets is now prohibited. This was accidentally allowed as noop in the past, but was warned about since early 2018 (Warn on pointless #[derive] in more places #50092), despite that crater found a few such cases in unmaintained crates.
• Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization, Ambiguity between custom derive attributes and proc macro attributes #52226 (comment)), but it was hard to do without fixing expansion order for derives. The deprecation is tracked by Tracking issue for deprecation lint legacy_derive_helpers #79202.

    #[trait_helper] // warning: derive helper attribute is used before it is introduced
    #[derive(Trait)]
    struct S {}

Crater analysis: #79078 (comment)

[petrochenkov]

@bors try

[bors]

⌛ Trying commit 914c2fe531ee84a0a40e42148a82b8ceb61b2fa9 with merge a5d5c8b18da6d26c8237c831cfda59089bccf845...

[petrochenkov]

@bors try

[bors]

⌛ Trying commit 71cf3396c9d44524cfcbbea1a375cdb2fd63871b with merge 7f64738202675455a69bc6bb3e27b8186ef98cb6...

[bors]

☀️ Try build successful - checks-actions
Build commit: 7f64738202675455a69bc6bb3e27b8186ef98cb6 (7f64738202675455a69bc6bb3e27b8186ef98cb6)

[petrochenkov]

@craterbot check

[craterbot]

👌 Experiment pr-79078 created and queued.
🤖 Automatically detected try build 7f64738202675455a69bc6bb3e27b8186ef98cb6
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🚧 Experiment pr-79078 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[pksunkara]

I am a little late to the party, but is there any reason why some of those are feature gated?

[petrochenkov]

@pksunkara
See #79078 (comment) and comments from lang team members above.
I think the primary goal was to avoid empty #[derive()] being abused as #[cfg_eval].

The good news is that I plan to make a PR for proper #[cfg_eval] in the next couple of weeks, after it's merged feature(macro_attributes_in_derive_output) will be able to start stabilization.
It doesn't really add anything new - #[derive(Foo)] ITEM fully expanding #[cfg]s for Foo is a well-defined and relied upon behavior, and #[derive(/*anything*/)] #[foo] ITEM (or #[cfg_eval] #[foo] ITEM) doing the same thing for foo is no different from that.