Integration with image

[theotherphil]

When this library is sufficiently well featured and stable we should remove the overlap between it and the image crate. Everything in image::imagops looks to naturally belong here, but before doing that we need to:

1. find uses of those operations in other crates (this is hopefully as easy as just using cargo-crusader),
2. get agreement from the authors of the image crate!
3. decide how to handle DynamicImage. This currently forwards each of the stable-and-fairly-short list of imageops functions to those on the corresponding GenericImage. It's not sensible to just keep growing this list forever, but the simplest use case of load -> op -> save should remain as simple as possible.

[ripytide]

I've opened image-rs/image#2238 and the maintainer seems open to the idea of migrating functionality on a case-by-case basis.

My current action plan is to individually migrate all/most of the functionality from imageops to imageprocs starting with the most imageprocs relevant functions. After each function is integrated into imageprocs then the image crate maintainers can then deprecate the functions which would allow them to remove them at some point in the future after users have hopefully migrated.

How does that sound?

decide how to handle DynamicImage

Looking through the imageops code it seems most functions are now simply using GenericImageView traits exactly how most current imageprocs functions are implemented which might make things much easier than they might have been previously.

[theotherphil]

Let's consolidate discussion on the image crate issue - I'll close this one.