Hide tonemap_exposure from editor when using Compatibility with BG_CANVAS.

[allenwp]

Issue description

Tonemap exposure does not work with the Compatibility renderer when the Environment background mode is set to Canvas:

1. Create a new 2D scene with the Compatibility renderer
2. Add a WorldEnvironment with an Environment
3. Set background mode to Canvas
4. Optional: Enable BCS color adjustments or glow to force post.glsl to be used
5. Adjust tonemap exposure
6. Note that the exposure adjustment does nothing

This issue is reproducible as far back as v4.3.stable.official [77dcf97]. In earlier versions of Godot 4, it is still reproducible, but the Canvas background mode seems to not function at all.

This issue is entirely separate from the issue that is fixed by #113861 as demonstrated by the optional step 4 that forces post.glsl to be used.

This PR

• Fixes Compatibility: Canvas tonemap does not always work and exposure never works #110902 (half of the issue)

This PR simply hides the non-functional tonemap exposure parameter in the specific configuration where it does not function. I have updated the docs to note this limitation.

Additionally, I have removed the old note that I had introduced as a part of #102820 that said: Values provided to the tonemapper will also be multiplied by 2.0 and 1.8 for [constant TONE_MAPPER_FILMIC] and [constant TONE_MAPPER_ACES] respectively to produce a similar apparent brightness as [constant TONE_MAPPER_LINEAR]. At the time I wrote this, I assumed it must be true, but for some scenes this is not true: The extra 2.0 and 1.8 multipliers actually make Filmic and ACES sometimes appear much brighter than Linear. So I really don't know why these extra multipliers exist and should never have added this unhelpful note in the first place.

Why not just add support for exposure to Compatibility with BG_CANVAS?

I looked into this option and discovered that it is probably not worth it. Here is the summary of my decision:

1. Exposure must be applied to linear-encoded colour values
2. Exposure should impact the glow effect
3. The glow effect texture is currently generated based on nonlinear srgb-encoded values that have exposure baked in (in the case of 3D scenes)
4. The glow effect is applied before converting to linear values in post.glsl to match the encoding that was used to create the glow texture

So currently, the behaviour is correct and as expected. If I were to add an exposure to post.glsl, it would not correctly interact with the existing glow functionality's colour encoding.

Maybe there is a way to work around this, but honestly I expect that very few people would even need this exposure feature for this specific configuration, so simply hiding it in the editor sounds to me like the correct choice. If there is a strong demand for the feature, we can try and solve this complicated problem then.

Cherry picks

I've added the cherry pick label for 4.4 and 4.5. Another label for 4.3 could be added, but I've chosen to omit this because the docs change will conflict. (It's a trivial conflict, though, so we could even cherry pick it to 4.3 if that's desired.)