I haven't put reshape operators into the SRFI because, in general, they
are not affine, so they don't compose with the other existing array
transformations.

But there is one important class of reshape operators that *are* affine,
where one maps the elements of a d-dimensional array lexicographically
to a one-dimensional array with the same volume.  (The inverse
transform, for example, is not affine.)

In all my years of working with this library I've never had a need for
these, and I didn't even think of their existence until tonight.  (I
don't know why, the basic mapping of indices to the linearly accessed
body of a specialized array is of this form, but there it is.)

Reshape operators cannot in general be computed from the other array
transformations, except by specifying the appropriate transformation
directly in specialized-array-share.  That's one argument for putting
them in the SRFI.

On the other hand, they are a bit clumsy to implement for
non-specialized arrays, but I suppose it's not too bad.  It would
basically be building an affine transformation over the indexing of a
general array, if I'm making any sense.  I already discussed that
possibility in the SRFI and rejected it in favor, e.g., of permuting the
arguments of an array-getter directly for array permutations.  But for
reshape operators I don't see any simpler way, off hand, than just
computing and saving the indexer function from the new multi-dimensional
array to the existing one-dimensional array.

Any thoughts?  If this is an important array transform, I wouldn't want
to leave it out, but adding it would delay this SRFI a bit more.

Brad