Methods .mapv(), .mapv_into(), .apply(), .applyv(), .visit()

[bluss]

Fixes #58
Fixes #153

I did experiment with a trait to unify the map and mapv case into a single method, and while it worked, it also introduced type inference ambiguities everywhere, so it was so much less useful.

[bluss]

I am taking suggestions for a good naming scheme for the methods .map(), .mapv(), .apply(), .applyv(), .visit().

We do want them all as this kind of "internal iteration" or closure visiting; it's the only way we can optimize the traversal across nested loops if needed.

We do want both .map and .mapv and the same with .apply, .applyv, because the by value methods are so convenient for numerical code.

[daniel-vainsencher]

Map should definitely stay map. Apply doesn't explain that mutation is going to happen. Maybe transform? I doubt I'd ever find out about the v versions, I would be using & because I've gotten used to this inconvenience :( I don't have a better name, though. Visit is fine, IMO.

[bluss]

Thanks for the input! They will be next to each other in the docs, so I hope you'd see them there.

This is tricky because mathematically, all four methods do the same thing. So we're trying to find words for that..

[bluss]

Oh no, there's yet another one that comes up, mapv_into. (Map by value, return the input).

Again, all of these are the same mathematically, just with different rust type system effects.

 .map(&self, |&A| -> B) -> OwnedArray<B, D>
 .mapv(&self, |A| -> B) -> OwnedArray<B, D>
 .mapv_into(self, |A| -> A) -> Self
 .apply(&mut self, |&mut A|)
 .applyv(&mut self, |A| -> A)
 .visit(&self, |&A|)