Allow (but don't require) #[unsafe(naked)] so that compiler-builtins can upgrade to it

[c4rtune]

tracking issue: rust-lang/rust#138997

Per rust-lang/rust#134213 (comment), we want to make the #[naked] attribute an unsafe attribute. Making that change runs into a cyclic dependency with compiler-builtins which uses #[naked], where rustc needs an updated compiler-builtins and vice versa.

So based on rust-lang/rust#139753 and #t-compiler/help > updating `compiler-builtins` and `rustc`, this PR allows, but does not require #[unsafe(naked)], and makes that change for some of the tests to check that both #[naked] and #[unsafe(naked)] are accepted.

Then we can upgrade and synchronize compiler-builtins, and then make #[naked] (without unsafe) invalid.

r? @traviscross (or someone from t-compiler if you're faster and this look allright)

[MonnetalX]

🔍 PR Link Analysis

🔗 Ranked Links

#1 rust-lang/rust#139753

🔍 The #[naked] attribute is now an unsafe attribute in any edition, creating a cyclic dependency where updating the compiler requires updating compiler-builtins and vice versa.

#2 rust-lang/rust#138997

🔍 The #[naked] attribute is being made unsafe, requiring a feature gate for naked functions with the Rust ABI to manage this transition.

#3 rust-lang/rust#134213 (comment)

🔍 The #[unsafe(naked)] attribute prevents the compiler from emitting a function prologue or epilogue, analogous to __attribute__((naked)) in C.

#4 #t-compiler/help > updating `compiler-builtins` and `rustc`

🔍 The #[unsafe(naked)] attribute is being introduced to allow compiler-builtins to upgrade without creating a cyclic dependency with rustc.