Packed Arrays could use some more trait impls

[lilizoey]

For instance, you cannot currently do

let v = vec![Vector3::new(1.0, 2.0, 3.0)];
let packed: PackedVector3Array = v.into();

This could be fixed with a From<Vec<Vector3>> impl for PackedVector3Array.

In general since packed arrays are very similar to Vec we could also take inspiration from what Vec has implemented.

See discussion below for more details.

Traits to implement:

• From<Vec<T>>
• From<[T; N]>
• From<Array<T>>
• From<PackedTArray> for Array<T>
• Index and IndexMut, i think we can use I: SliceIndex like Vec does.
• IntoIterator
• Write, for PackedByteArray only but preferably have a use-case first

Other trait impls we can consider:

• Deref and DerefMut to [T]. may conflict with Godot's api for packed arrays
• From<Box<[T]>>, From<VecDeque<T>>. We can already do this with collect()
• AsRef<[T]>, AsMut<[T]>, Borrow<[T]>, BorrowMut<[T]>. Should have a use-case first

Additionally we apparently have From<&VariantArray> for PackedVector3Array etc, which is wrong. (looking at the implementation this might actually be UB).

[Bromeon]

Definitely agree it makes sense to provide easier conversions between Packed*Array and Vec or slices. Thanks for the list!

As mentioned in #297, we should make sure these satisfy common use cases. Otherwise, with this being marked good first issue, the risk is that newcomers just start working off the list of traits.

Some things to keep in mind:

1. Deref/DerefMut is mostly convenience for as_slice()/as_slice_mut(). However, since packed arrays have their own API inherited from Godot, it may actually be worth to keep this explicit. There are some overlapping methods like binary_search or contains which are using different implementations.
2. From<Vec> may be more explicit as from_vec constructor
3. From<Array> could also be a method Array::to_packed() or Packed*Array::from_array()
4. From<Box<[T]>> and From<VecDeque<T>> are extremely niche, possibly better via collect()
5. std::io::Write would also need a concrete use case. Since they operate on [u8], it may only really be useful for PackedByteArray
6. Index/IndexMut definitely make sense
7. AsRef/Borrow need use cases

---

Additionally we apparently have From<&VariantArray> for PackedVector3Array etc, which is wrong. (looking at the implementation this might actually be UB).

Interesting, we should remove that. Even without looking at the implementation, From should be infallible, which this can't be.

[lilizoey]

I'll update the issue to reflect some of these comments.

1. Deref/DerefMut, that makes sense.

I think From<Vec> would be good to have even with a from_vec constructor because you can then do vec![a,b,c].into(). In general i think From<X> methods are nice to have as long as it's appropriate and there isn't a good reason not to have it, such as it being surprisingly expensive or something one should be careful about using for some reason. But i dont think there are any particular reasons to not have From<Vec> or From<Array> here.

Having from_vec, to_packed and from_array additionally could make sense, but if i had to choose between those and From impls i'd prefer the From impls.

4. That also makes sense to me, Box<[T]> and VecDeque<T> both have FromIterator<Item = T> impls.
5. If someone wants to implement Write for PackedByteArray that'd probably be fine imo. I can imagine it being useful. But i do agree it'd be better for there to be an actual use-case first.