Add GenericImageView::try_view

[imlazyeye]

This adds GenericImageView::try_view as a non-panicking alternative to GenericImageView::view. It additionally updates the documentation of GenericImageView::view to mention its panics.

I am writing a non-panicking binary that captures screenshots of a window. If the user resizes their window unexpectedly, the coordinates/dimensions I pass in to GenericImageView::view may become invalid. I would like to be able to get an Err so I can handle this behavior myself.

I am unsure if the error I utilized here is correct within this context -- please let me know if there is another I should be using/if I should create a new one!

[197g]

The error type is fine with me, another variant would be returning Option but imo try_ is a better pattern as we have an error here. The error itself is consistent with other choices.

[fintelia]

I think Option is generally preferable for try_ methods that have only one failure mode.

We should certainly add the "panics" section to the docs on the view method, but I'm not convinced on adding try_view. It feels very specialized and reasonably straightforward to work around in user code.

[197g]

The responsibility of the implementation of the check seems to me like it should belong in our code. Similar to the standard library having added checked variants of split even though for a long time it had the argument that its precondition would be simple to check. And mind you, in comparison this precondition is harder to get right due to overflows.

[imlazyeye]

Agreed, I think there's precedent for crates guiding users through what failure states could occur through the return of their types, not just the documentation. It's still the user's responsibility to handle this error case, but I think the crate is responsible for guiding the user through what errors they will potentially run into.

I think Option is generally preferable for try_ methods that have only one failure mode.

Typically I follow the same philosophy, however in cases where your error case is the result of a mistake rather than "there is not something there", Result feels more appropriate. I think there's an argument both ways for where this particular example lies, but personally Result seems most natural.

[imlazyeye]

redid above work after rebasing to main's refactor