Add L32F and La32F to ColorType and DynamicImage

[mstoeckl]

This adds new L32F and La32F ColorType entries.

My motivation here is mainly to make it easier to decode image formats that can contain L32F pixels (TIFF, EXR, and perhaps PFM), but this change also the nice benefit of making DynamicImage's subformats form a grid of pixel dimensions and subpixel type, so that operations like DynamicImage::grayscale reliably produce a Luma or LumaA image, and we could later add methods like to_32f that affect the subpixel type but not the pixel component count.

See also a previous attempt at this in #1846, and the recent change adding L32F and La32F ExtendedColorTypes in #2793.

There is a lot of casework involved in this MR; I think I've updated or added every function that needs adding, but it's not impossible that I missed something.

[RunDevelopment]

Great stuff!

I really like the symmetry between color types this creates. I'm also surprised by how little code you needed to change to make this happen. I expected it to be much more.

[fintelia]

If you're going to relitigate intentional design decisions that we previously made (even citing the previous thread where I stated that these variants intentionally left off!) then please start with a issue thread explaining what has changed/why we should reconsider, rather than jumping straight to a PR.

[RunDevelopment]

@fintelia Could you please state the intentions/reasons behind this design decision? The previous comment you referred to only states that this decision exists, not why.

[197g]

What definitely did surface since then is that, while implementing color conversion, it was noted that DynamicImage::to already had to deal with all the complexity of having LF32 and LaF32, without having any of the tools of ColorType which made the whole interface somewhat absurdly odd. (And as a consequence, it was impossible to make it color space aware). If ColorType was designed as a product-type between channel type and color model instead, which this PR would result in, that would allow other designs to much better rely on dispatch as a solution to this instead so they deal with each of those dimensions individually rather than coupled.

[197g]

Expanding on the above, concretely it was impossible to add to_alpha_mask and a setter for DynamicImage due to the lack of pure luma variants for all color types.

The design decision I remember is to use a small subset of variants we can get away with as informed by combinations occurring real world image files. We also have those here now or in the forseeable future: unassociated alpha, uncolored image data, 3d-depth data, and more scientific files (tiff but also JPEGXL) support 24-bit or 32-bit colors in floating point. We additional made another design choice of performing color conversion when loading into DynamicImage (i.e. simplify it so not everyone has to deal with YCbCr and so on); but such conversion results in banding for non-linear rescaling; will always require clipping which makes it impossible to represent HDR data where non-SDR has larger-than-1 samples; in particular ICC support would benefit from non-clipped 32-bit data with single-channel images.

[mstoeckl]

Apologies @fintelia , I see now that you've replied on this topic many times in the past. I've linked to some of the issues/PRs in #2935.