move_into: Split into methods .move_into() and .move_into_uninit().

[bluss]

Two methods for Array:

• .move_into(impl Into<ArrayViewMut<A, ..>>)
• .move_into_uninit(impl Into<ArrayViewMut<MaybeUninit<A>, ..>>)

The uninit version is an optimization - it is more efficient since we don't need to keep track of the overwriting of existing values in the array. However, we optimize so that if A has no drop, they should be equivalent. So the user can use whichever fits best without worrying so much.

The new move_into turned out to be very simple: just swap the elements in the old and new array. This means we never have a partially moved-from array to keep track of and no headaches. We simply delegate over to the non-drop method if we can. We also use a needs_drop check in move_into_uninit to skip all the complicated dropping code if the element type doesn't have drop.

[bluss]

The comment on why a public into_maybe_uninit() conversion is problematic, it disappeared after the force push:

If we have an Array1<Option<&i32>> and make an ArrayViewMut1<MaybeUninit<Option<&i32>> from it, we can fill it with uninit or zeroed elements in safe code, which ends up messing up the original Array1. 🙁

(Something in type theory about mutability leading to that the type constructor having to be invariant.. something like that.)