Changes to the iterator

After benchmarking the iterator on DecodingError::NoMoreFrames again returning early I found that the early return is constantly around 8-10 percent faster on a webp animation with 6 frames (tested on two machines and 10_000 iterations). Therefore I changed the implementation to check at the start using a internal counter.

Testing

I also implemented a simple test which is checking against the internal framecount of the image_webp::WebPDecoder::num_frames(). The test is run against the 3 files in webp/extended_images which I believe to be a good representation of the expected behaviour.

advertises_rgba_but_frames_are_rgb.webp: returns the first two frames and the rest as a EOF decoding error. The iterator still exists after the specified frame-count of 12 .
anim.webp returns all frames.
lossy_alpha.webp: (not animated webp) returns one frame.

Let me know if something else should be implemented let me now. We could also check the first returned frame against the image returned by image::open, which would also be expected to be for all inputs. I wasn't sure if more tests are welcomed.

(Also I'm not sure about the clippy check failing. It also fails on my computer on the main branch so I assume it's not my fault)

(Also I'm not sure about the clippy check failing. It also fails on my computer on the main branch so I assume it's not my fault)

clippy is linting that there are some cfg-options that do not correspond to actual features we have in Cargo.toml. Huh, weird, but definitely not your fault.