Allow derives to `allow(non_ascii_idents)` at the non-crate level

[joshlf]

In google/zerocopy#2880, a user reported that our use of non-ASCII identifiers in generated code triggers the non_ascii_idents lint in their codebase.

In google/zerocopy#2882, we tried to solve this by emitting allow(non_ascii_idents) in derive-generated code, but this unfortunately has no effect, simply triggering this warning:

warning: allow(non_ascii_idents) is ignored unless specified at crate level
  --> zerocopy-derive/tests/issue_2880_expanded.rs:77:9
   |
77 |         non_ascii_idents,
   |         ^^^^^^^^^^^^^^^^
   |
   = note: `#[warn(unused_attributes)]` (part of `#[warn(unused)]`) on by default

This "crate-level only" behavior is also true of a number of other lints (for example). This restriction prevents us from using non-ASCII identifiers in generated code, which we intentionally do in order to minimize the likelihood of identifier conflicts with surrounding code. It would be good to support this in derive-generated code.

We propose one of the following:

• Lift this restriction
• Lift this restriction within code annotated with #[automatically_generated]
• Implicitly suppress this lint within code annotated with #[automatically_generated]

cc @jswrenn

[nxsaken]

Nominating since it has been brought up at today's Rust for Linux meeting.

[joshlf]

#157497 addresses this by going the minimal route: Just allowing non_ascii_idents elsewhere (not just at the crate top-level). It's just one option, so feel free to close if that's not the route we want to go.

[ojeda]

@rustbot label A-rust-for-linux

(It would allow us to remove a custom zerocopy patch in our vendored copy)