Upgrading to 2024 edition

[michaelciraci]

This PR generated by following edition transition guide

• cargo edition --fix
• Updating Cargo.toml
• Running cargo fmt on edited files

[HEnquist]

Thanks for taking this on. A few notes:

• The expr to expr_2021 rewrites aren't needed. Every macro in the crate is private (no macro_export), so all call sites are visible, and none pass a const block or _. I reverted them locally and edition 2024 builds fine with plain expr, with an identical warning set. I'd drop those hunks.

• cargo fix --edition only sees the active target, so this only covers neon. sse, avx, wasm_simd and fcma haven't been migrated, and nothing here has been checked on x86 or wasm.

• The edition bump adds ~4900 unsafe_op_in_unsafe_fn warnings, which is the actual bulk of the migration. cargo fix can apply 216 suggestions, the rest need real edits. Note that ~170 of them are a different case: calls into stdarch intrinsics that are now safe #[target_feature] fns, where the warning is that the enclosing fn lacks the matching feature. Since 1.86 stabilized safe #[target_feature] fns, those are better fixed by putting #[target_feature(enable = "...")] on our wrappers, which then lets them stop being unsafe fn at all. That's a separate refactor and shouldn't block this PR, but it would be a nice follow-up, and it would move the feature requirement into the type system instead of a comment.

• The fmt pass reformatted src/neon/neon_prime_butterflies.rs, which is in the ignore list in rustfmt.toml. That option is unstable, so stable cargo fmt skips the list without saying anything. Please use cargo +nightly fmt here. Edition 2024 also bumps rustfmt's style edition, which is where the big butterflies.rs diff comes from.

[ejmahler]

It's not necessarily worth spending a ton of time on, but if we can update the prime template to output code that the formatter is happy with, it can help our code be more idiomatic. I think it would be too fragile to ever remove the ignore entries, but even keeping them ignored from the formatter I think it would be worth it.

[HEnquist]

Alternative to tuning the template: have the generator pipe its rendered output through rustfmt before printing, and in --check mode too so the two stay in sync. Nobody hand-edits these files, so it doesn't matter what the template emits as long as rustfmt agrees with it, and rustfmt can just do that itself. I tried it, the changes are all mechanical (whitespace, import order, wrapping) and a second pass is a no-op.