bug in IL_NUM_IMAGES for animations

[WilbertD]

There seems to be some issues with IL_NUM_IMAGES:

• IL_NUM_IMAGES is always one off. Is that intended? http://docmorph.nlm.nih.gov/docview/distrib/v43n1a1.tif has 3 pages, but IL_NUM_IMAGES returns 2. (ilActiveImage(n=0;1;2) loads all three of them though)
• IL_NUM_IMAGES always returns zero for mng. http://entropymine.com/jason/mngplg/bouncing_ball.mng has 12 pages for example (according to xnview), but IL_NUM_IMAGES returns zero. ilActiveImage(n) loads only one page.

[bcampbell]

See also #34.

The current implementation of IL_NUM_IMAGES returns the number of images after the currently-bound image. So the result returned depends upon which frame you're currently on (eg if you're on the first frame of a 10 frame animation, IL_NUM_IMAGES will return 9. If you're on frame 2, it'll return 8. And so on.).

The animation support is really fuzzy. I'm planning to do some cleanup to clarify how it all works.
Basically, I think that:

• IL_NUM_IMAGES should always return the number of images in the whole animation, regardless of which frame you're on.
• ilActiveImage(N) should jump to frame N in the anim, rather than advancing N beyond the current frame (currently it advances N frames from the current one - see ilActiveImage() is unclear #34).

The obvious loop is:

num_frames = ilGetInteger(IL_NUM_IMAGES);
for(n=0;n<num_frames; ++n) {
    ilActiveImage(n);
    ... do stuff with frame n...
}

But this doesn't work with the current code. I think it should.

Most of these same issues also apply to Mipmaps, Layers and Cubemap faces.
And obviously, it gets even more complicated when you want to deal with, say, animated cubemaps with mipmap levels ;-)
So I think my planned changes will break the API... but then I feel it's not too big a deal because the API is already pretty broken in this respect. Feedback welcome!