Remove DynamicTga

[rfuest]

This draft PR is a possible solution to the color type problems we encountered in tinybmp. I didn't want to experiment with that project until the open PRs are merged.

The fundamental change in this PR is that Tga no longer accepts any C which has the same BPP as the image. Allowing any color type didn't make sense, because the color format is defined in the header. A C with the same BPP could represent completely different colors, e.g. Rgb888 and Bgr888.

Tga now behaves very similar to the removed DynamicTga. The C type parameter no longer specifies the format the image is stored in and is instead equal to the DrawTarget color type. The required bounds are changed to C: PixelColor + From<Gray8> + From<Rgb555> + From<Rgb888>, which is valid for all e-g color types and isn't hard to implement for custom color types. Tga will now be easier to use, because it's no longer necessary to specify the color type explicitly, when a Tga object is created.

The ImageDrawable impl is centered around a modified Pixels iterator. The iterator does now have two type parameters, one for the image color type and one for the target color type. This makes it possible to move the match statement over the image color type outside the iterator. By converting the colors in the iterator it isn't necessary to use color_converted draw targets, which should help with binary size.

To keep the Tga::pixels method working a pseudo color type Dynamic is used. It uses a different implementation of the iterator, which includes the match over the color type in the next method.

TODO:

• Test impact on performance and binary size
• Remove color table lookup from RawPixels

[rfuest]

@jamwaffles It would be too early to review this code in detail, but I would appreciate some initial feedback if you think this is going in the right direction.

[jamwaffles]

I like where this is going so far. The removeal of DynamicTga is a welcome change to make the API simpler.

[jamwaffles]

More a note to self when I review this proper: This error variant would need renaming too.

[rfuest]

The docs could still use some work and they will also need to be updated to intra-doc links, but that could be handled in another PR.

I didn't do any thorough benchmarks or binary size comparisons with the old version, but at least compared to DynamicTga I did get -15% to -65% runtime reduction. The binary size will have increased, because there are now optimized drawing routines for every TGA variant. If this becomes a problem in the future I would suggest that we add cargo features to disable uncommon formats like top right and bottom right image origins.

[rfuest]

@jamwaffles Could you also fix the required CI checks when you review this PR?

[jamwaffles]

Looks good, just one small nit in the changelog.

[jamwaffles]

Did we discuss long ago in the e-g repo that changes like this don't make much sense in the changelog?

[rfuest]

Yes, we did and I removed the entry from the changelog.