Add copying `IntoIter` implementation

[Gaspard--]

Apologies if any terms aren't right, I'm still learning rust.

Currently, if you want to return an iterator consuming a temporary variable, you can't, because IntoIter is only implemented for &T and &mut T.

    // Works, because arrays implement IntoIter returning f32
    for x in (|| [0.0f32, 1.0f32].into_iter())() {
        print!("{}\n", x);
    }
    // Does not work, because nalgebra::Vector2 does not implement IntoIter returning f32, so the compiler picks &f32 instead
    for x in (|| Vector2::new(0.0f32, 1.0f32).into_iter())() {
        print!("{}\n", x);
    }

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=e3c5472e96dbe560be70cf3c5e55c6b8

I was wondering if would possible to add the missing to implementation to support this? Is there some potential technical limitation I can't see?

Note that it's currently possible to work around this problem for very simple situations by chaining iterators over copies of each field.

[Ralith]

Doesn't seem obviously unreasonable. Give it a try and see what rustc thinks?

[Gaspard--]

I tried looking into it, and it seems that the implementations of IntotIter use MatrixIter which seems to only support references: https://github.com/dimforge/nalgebra/blob/0e8aed8809999313f0d964341e7dd83b6f1f742d/src/base/iter.rs#L246-L247

I guess this means we'd need a new type of iterator or something to handle the missing version of IntoIter.

[Ralith]

Yep, that's what a new iterator is.

[Gaspard--]

I didn't have time to look much further, but I've come to the conclusion this might be a breaking change (?) because the existance of IntoIterator for X will cause the compiler to pick it instead of IntoIterator for &X if I understand how traits function right.

This changes this issue from "add support for X" to "change behaviour X" which I imagine might be unreasonable?

[Ralith]

We have a breaking change queued up anyway due to rand's update. I vote we go for it.