Add sampling using [0,1] for GenericImageView

[JulianKnodt]

WIP
Not sure whether this should directly go on GenericImageView, and where the enums should go.
Also need to add tests but put the general idea up for review.

---

Adds a way to sample images in [0,1], which is a common use case in graphics.

Currently adds non-exhaustive enums based on OpenGL's that allow for simple sampling of nearby coordinates.

Nearest sampling can produce artifacts depending on the sampling resolution of the UV whereas bilinear will smoothly interpolate.

Addresses #1905

[fintelia]

Looking at these changes, I think adding bilinear sampling to this crate is valuable but I worry that a generic sample method is going to add too much complexity. There's just so many different ways to sample an image with a (f32, f32). For instance, there's the question of whether (0,0) is the center of the top left pixel (like in this PR) or the corner of that pixel (like the usual convention in OpenGL/Vulkan/etc.) and that's on top of questions about wrapping mode and filtering method. And no single option is "right"

What would you think of adding just a bilinear_sample method that always clamped to edge and used the same coordinates as get_pixel (ie from 0 to size-1 with integer values being pixel centers). It shouldn't be too hard for users to implement wrapping or normalized coordinates based on that if they want

[JulianKnodt]

I think that's definitely a step forward.
I do think that being able to switch between different sampling modes is very convenient, so I think keeping the SampleKind is good, and would let additional sample kinds be added more easily in the future.

I think that clamping against the edge quietly is probably going to lead to unexpected behavior for users. Instead, we should probably return an Option<Pixel>, and that will be immediately clear to the user that they've sampled out of bounds, as long as we guarantee that all values in [0,1] do not return None.

[JulianKnodt]

Just wanted to bump this, while I am pushing back on some ideas you suggested, if you feel strongly about them I will change it. I would rather have sampling in some form than no sampling.

[fintelia]

Let's go with one method per supported sampling type. If users want to dynamically pick between sampling types, they can implement it themselves, but this way there's no extra branching if the sampling type is known in advance.

Thinking about it, the methods probably belong in the imageops module with all the other methods implemented for GenericImage[View]

[JulianKnodt]

Sounds good, it may take me a bit to implement but I'll add them in.

[JulianKnodt]

Cheers, was out of town but have fixed most of the comments

[JulianKnodt]

@fintelia You're gonna have to merge it, I don't have the ability to do so