Allow processors to generate multiple images

The approach by @larowlan seems very useful to me, as it means existing modules are unaffected and new ones can receive additional information via the new interface. Over time perhaps some more helpers can be added for moving temporary files too but this would be a good start and works great for me.

I thought this was interesting: WebP fallback image → .. Their argument is that we aren't gaining the full benefits of compression with modules like ImageAPI Optimize Webp → because we aren't compressing from the source file. My original rationale was to avoid running images through image style processors multiple times(once as jpg, once as webp, for example), though that wouldn't matter so much if it's only running it through the image style as it's being requested for the first time. I think it's also more and more likely that people will favor AVIF with a WebP fallback, and almost never want to keep the original file format if JPG, PNG, etc..

Perhaps finding a way where we would no longer need to do the derivative handling at the imageapi_optimize level, and let optimize just worry about optimization.

I haven't looked at this stuff in awhile and will try and get caught back up.

8.x-2.x branch is no longer supported, so moving to needs work for a porting.

Is this feature request still relevant for the 4.x branches? If so it seems the version should be updated. If not I guess this could be closed as outdated. Thanks!

@greggles, we are working on a new approach to image type derivatives so that we can support more complex workflows, for example:

Original image is .jpg

• Generated AVIF
• Generated WebP(fallback)
• Original JPG (removed from display)

Original image is .webp

• Generated AVIF
• Original WebP(fallback)

Original image is .avif

• Original AVIF
• Generated WebP(fallback)

This will also allow builders to mix in other standards, like if you have a photography site or maybe product shots and want to use Jpeg XL(with webp fallback) for those displays. We are nearing completion, and have a solution for this, although not the most elegant. Ultimately we will override the ImageStyle entity class and have versions that support core and imageapi_optimize when enabled. Because we are trying to support both core and imageapi_optimize versions, I'm not sure a solution here really save us too much effort. Ultimately a solution might be a better fit for core.