Add methods .cell_view() and .into_cell_view()

[bluss]

Add ArrayBase::cell_view (similar to methods .view() and .view_mut()) and the conversion method ArrayViewMut::into_cell_view()

We've wanted to add these methods since we added .cast::<T>() to the raw views.

The translation of ArrayViewMut<'a, T, D> -> ArrayView<'a, MathCell<T>, D> works under the same principle
as the method Cell:from_mut in the standard library.

These methods should give a lot of flexibility - suddenly the same array view can be traversed multiple times
in the same Zip and mutated while being traversed in a different way than before. The price to pay for this
is using the Cell methods to manipulate the elements.

We use a new cell type - MathCell - which is just a transparent wrapper around Cell. This is so that
we can implement arithmetic ops for cells. However, finding the right implementations requires more design
work so that will be in a later PR.

This fixes #478 - the use case is fixed by using Zip::from(a).and_broadcast(b.cell_view()) - i.e composing cell_view
with the existing broadcasting method.

[bluss]

Oh, now I remember why I didn't add this before. I wanted to wait for adding some kind of ArithmeticCell<A> which would be easier to use transparently in arithmetic ops. See #478 (comment)

[bluss]

Any preference between the names MathCell<T> and ArithCell<T> for the arithmetic ops supporting (transparent) Cell<T> wrapper? I think MathCell<T> would be a good name. Or should it just use the name Cell<T> in the ndarray crate, or too confusing? Also - the expectations are low for arithmetic ops on such a type, it's hard to get all the combinations that one would want to work.

[jturner314]

IMO, reusing the name Cell for a wrapper would be too confusing. Either MathCell or ArithCell would be fine with me. Other options are OpsCell and AutoCell.