Implement loop_count for AnimationDecoder Trait.

[rayguo17]

As described in #2715, This PR implements loop_count function for AnimationDecoder Trait, currently there are three type (Gif, Webp and Apng) implementing AnimationDecoder Trait, so implementation on these specific format decoders are added.

[197g]

Seems agreeable. (fyi, I'd rather we merge this PR to introduce the type and then I adjust #2672 where the AnimationDecoder trait was removed. It fits well with the is_animated field that got added there.)

[rayguo17]

(fyi, I'd rather we merge this PR to introduce the type and then I adjust #2672 where the AnimationDecoder trait was removed. It fits well with the is_animated field that got added there.)

Do you mind explain a bit on the change for AnimationDecoder in #2672 ? I look through the code, and seems to me the PR only change the implementation of the iterator, and still implementing AnimationDecoder.

[197g]

The PR replaces what AnimationDecoder can do with simply calling read_image itself multiple times. That rids us of the awkward dance where you can't easily optionally have an AnimationDecoder by moving that information into decoder or file attributes. (Deleting the actual trait would be the last commit on the PR or after it, once we're clear that all functionality replacement is good to go).

[rayguo17]

Hey @197g , I wonder what is the release procedure of image crate? When do you plan to do the next release?

[197g]

Since the next planned to be new major bump (#2245), it may be a bit for the fully intended one (1st March?) to tie up the lose ends of animation. That said there were a few fixes in the underlying codecs and a bunch on tiff that might warrant doing a 0.25.10 and backporting this. It depends on capacity vs interested I suppose