cm: higher-quality tonemapping

[njdom24]

Describe your PR, what does it fix/add?

This PR is targetting screenshare.

Inspired by KWin. Updates the tonemapper to use the src imageDescription's luminance info instead of throwing it away. Also scales the reference luminance to match that of the destination, preventing over-bright screenshots / recordings.

Also tossed in a quick fix missed from #12094, which prevents overly-dark screenshares in SDR when render:cm_sdr_eotf > 0.

HDR screenshot tonemapped to SDR:

SDR screenshot:

I also considered a simple luminance multiplier as a proof-of-concept when getting started. This is what that would look like by keeping the current tonemap and simply multiplying the end result by 80.0 / 203.0:

Versus this PR:

The changes to blurprepare.frag fix the inverted color issue with blur from SDR->HDR.
Screenshot of my desktop in SDR:

And in HDR tonemapped back to SDR with these changes:

The blur is still too strong, but the colors are a lot better.

Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)

I'm not super confident in the "correctness" of tonemapper changes (really just looked at prior art), but it does improve HDR screenshares immensely.

Is it ready for merging, or does it need work?

Ready

[vaxerski]

@UjinT34

[UjinT34]

Current tonemapping is also inspired by kwin. If they changed theirs then we should probably do the same. Might be harder to track every necessary change because they combine cpu calcs, shaders and drm properties.
Tonemapping happens when source max luminance is higher than the target one. Most games set their luminance to 10000 or some other high value which almost always results in HDR -> HDR tonemapping. So this PR will affect desktop HDR and fullscreen HDR with cm_fs_passthrough = 0. Might make it better or worse but most likely it'll be too subtle to notice.

[njdom24]

@UjinT34 Thanks, I didn't consider that.
Do you think it warrants a check for HDR-on-HDR to bail, and maybe a new config var for that?

My HDR displays are all Mini-LED, so I can't be sure how it'll look on e.g. OLEDs with HDR400.

[UjinT34]

tonemap works with linear values and shouldn't care about SDR/HDR. I don't think we need a separate codepath for that unless someone has issues with HDR and new tonemapping.