Iterators conflict with any kind of multiversioning (not just in fearless_simd)

Nobody has claimed this yet.

`for x in iter { do_stuff(x) }` and `iter.for_each(|x| do_stuff(x) }` are not equivalent for the purposes of SIMD.

The difference is that `for_each` is a standard library function not annotated `#[inline(always)]`, so there is a function call barrier between the loop body and the outer function in the iterator formulation, but not in the for loop formulation.

So the `#[target_feature(enable = ...)]` annotations from the outer function are not propagated to the loop body in the iterator formulation.

This is problem for any kind of function multiversioning, not just in `fearless_simd` but also for the `multiversion` crate and every single other approach to multiversioning.

Writing `iter.for_each( #[inline(always)] |x| do_stuff(x) }` still doesn't reliably fix it, because inlining the closure into the `for_each()` is not enough, `for_each()` itself also needs to be inlined into the caller. Admittedly I haven't experimented with this extensively, but even if heuristics often line up and make it work, this is still fragile.

Here's an example of this issue manifesting in practice, where I had to rewrite a `for_each()` into a `for` loop to avoid a performance drop, but the setup remains fragile even after that workaround: https://github.com/smu160/PhastFT/blob/7bbbfa5bbac8681af7d1abf6fb02990d8eacb552/src/kernels/dit.rs#L998-L1041

Start by comparing the `for` loop and `iter.for_each` examples in the issue, then review the linked `PhastFT` code at `src/kernels/dit.rs` lines 998-1041. Reproduce the SIMD performance difference and investigate how `#[target_feature]`, closure inlining, and `for_each` inlining interact; done requires a reliable resolution that preserves multiversioning behavior without the workaround.

Written by the indexing model from the issue text.