Reorganize/rename items in public API

[jturner314]

I'm considering changing the public API as follows:

• Move .npz functionality into a separate crate
• Rename ReadableElement to ReadElement
• Rename WritableElement to WriteElement
• Rename read_npy to from_reader or read and change it to take R: Read instead of a path
• Rename write_npy to to_writer or write and change it to take W: Write instead of a path
• Rename write_zeroed_npy to to_writer_zeroed or write_zeroed
• Remove "npy" from the names of the error types and possibly the extension traits (but not the names of the methods in the extension traits)

[nilgoyette]

Move .npz functionality into a separate crate

I'm not for or against, but I wonder why you want to do that. Is there a problem with the current feature gate?

[jturner314]

The current feature gate is fine as-is, but there are a few advantages to moving the .npz functionality into a separate crate:

• The zip dependency could be updated without a breaking change to the ndarray-npy crate. (Updating zip would be a breaking change only for the .npz crate.)
• "npy" and "npz" could be removed from the names of some of the traits/functions/types, which would make the names shorter and more similar to naming conventions of other crates. (I'd recommend users to use ndarray_npy as npy; use (the npz crate) as npz;, then e.g. write_zeroed_npy would be npy::write_zeroed and NpzReader would be npz::Reader.)
• I think a separate crate is conceptually simpler than a feature.