VisualShader: Add LinearToSRGB and SRGBToLinear to ColorFunc node

[tetrapod00]

Implements and closes godotengine/godot-proposals#10818.

Adds LinearToSRGB and SRGBToLinear conversions to the visual shader node ColorFunc.

Implementation:
This node automatically switches it's conversion function depending on which renderer is used.

The RenderingDevice (Forward+ and Mobile Renderer) conversion functions:

godot/servers/rendering/renderer_rd/shaders/effects/copy_to_fb.glsl

Lines 121 to 130 in 4254946

	vec3 linear_to_srgb(vec3 color) {
	//if going to srgb, clamp from 0 to 1.
	color = clamp(color, vec3(0.0), vec3(1.0));
	const vec3 a = vec3(0.055f);
	return mix((vec3(1.0f) + a) * pow(color.rgb, vec3(1.0f / 2.4f)) - a, 12.92f * color.rgb, lessThan(color.rgb, vec3(0.0031308f)));
	}
	vec3 srgb_to_linear(vec3 color) {
	return mix(pow((color.rgb + vec3(0.055)) * (1.0 / (1.0 + 0.055)), vec3(2.4)), color.rgb * (1.0 / 12.92), lessThan(color.rgb, vec3(0.04045)));
	}

The Compatibility renderer uses slightly different functions:

godot/drivers/gles3/shaders/tonemap_inc.glsl

Lines 13 to 26 in 4254946

	// This expects 0-1 range input.
	vec3 linear_to_srgb(vec3 color) {
	//color = clamp(color, vec3(0.0), vec3(1.0));
	//const vec3 a = vec3(0.055f);
	//return mix((vec3(1.0f) + a) * pow(color.rgb, vec3(1.0f / 2.4f)) - a, 12.92f * color.rgb, lessThan(color.rgb, vec3(0.0031308f)));
	// Approximation from http://chilliant.blogspot.com/2012/08/srgb-approximations-for-hlsl.html
	return max(vec3(1.055) * pow(color, vec3(0.416666667)) - vec3(0.055), vec3(0.0));
	}
	// This expects 0-1 range input, outside that range it behaves poorly.
	vec3 srgb_to_linear(vec3 color) {
	// Approximation from http://chilliant.blogspot.com/2012/08/srgb-approximations-for-hlsl.html
	return color * (color * (color * 0.305306011 + 0.682171111) + 0.012522878);
	}

If #90187 is merged, and the change in that PR is also made to the GLSL version of the linear_to_srgb and srgb_to_linear functions, then this visual shader node will need to be updated.

[Geometror]

Originally, I wanted to suggest switching the computation based on the current renderer, but after looking at the referenced blog article, I think it would be fine to just use the compatibility version (since it's a very good approximation). Maybe it can be used for RD renderers as well. CC @clayjohn

[tetrapod00]

All else being equal, the visual shader node should be accurate to whatever computation is used in the current renderer (or, if it must make assumptions, favor the Forward+ and Mobile renderers).
But if the Compatibility approximation is both much faster and still very accurate, then it makes sense to use it for visual shdaer nodes, where you might be converting between color spaces repeatedly (if a node is there, it will be used!).

[tetrapod00]

The computation now depends on the renderer, exactly matching whichever computation is used internally.

[Mickeon]

Assuming accuracy, the docs are completely fine.

[Repiteo]

Thanks!