Add methods to collect Zip into an array

[bluss]

Add

• Zip::apply_collect
• Zip::apply_assign_into
• Zip::par_apply_collect
• Zip::par_apply_assign_into

Add internal (for now) constructors for MaybeUninit<T>-filled arrays.
Restrict to Copy elements to use collect (because we don't implement dropping a
halfway filled array yet).

This is added to all but the last arity of Zip (because the last item is needed for the result that we collect into.

The assignment functions are generalized so that we can assign to &mut T, &mut MaybeUninit<T> and &Cell<T> when we have elements of T. This seems powerful, and could be a concept that's explored further (methods .assign() and .fill() come to mind).
A very minor question is what to name and in which module to put the new trait for this - AssignElem<T>.

Fixes #755

[bluss]

In the grand scheme of things, it would be more exciting if

1. any NdProducer could be collected
2. Zip can be an NdProducer of tuples by default.
3. One could with a method - .map(f) - create a different NdProducer from a Zip value itself.

but it's not certain that the required changes are worth it. Or if @jturner314 hasn't implemented something similar already :)

[bluss]

Now using MaybeUninit, because Vec::drop is what makes it unsound to toss uninit elements around. This is a lot closer to what @jturner314 said all along. 🙂

[bluss]

For non-Copy elements (more specifically, elements with drop, but we don't have a trait bound for that); there are hints of solutions for collect - I have an unbeautiful prototype for counting elements and dropping the right number of them on panic; but this doesn't transfer at all to the parallel case (in the parallel case, we have multiple different "write heads" into the array, and they all need to "roll back" if any thread panics), and that's a sign a better solution is needed of that problem. So it's not coming here.

I'm also saying that I think it's important to handle drop correctly - on panic, the elements that were created should drop. It would be easy to ignore the problem by just saying that there is no drop handling, but I would judge that's not robust.

That said, if MaybeUninit arrays are just exposed, they are very useful and the user can decide themselves if they want to skip handling drops on panic.