Fix shader language float literal precision truncation

[bitsawer]

Fixes #77325
Fixes #78896

Related issue, but not affected by this PR: #78204

This PR simply replaces rtoss() with rtos(), which behaves much better with float/double precision and is also much more used in the Godot codebase. After this PR, rtoss() will only be used in one place in variant_parser.cpp. This should most likely also replaced with a better behaving version. However, the remaining issue is the underlying String::num_scientific(), which can sometimes drop too many decimals from float or double values, as documented in #78204.

Currently, the float literal conversion between Godot shader language and the final GLSL version can drop the float decimal part accuracy dramatically, which breaks many otherwise valid GLSL tutorials, demos and libraries.

Original Godot (or GLSL) shader code:

float rand(vec2 x) {
    return fract(cos(mod(dot(x, vec2(13.9898, 8.141)), 3.14)) * 43758.5453);
}

Raw GLSL code generated from Godot Shader Language (notice the dropped decimals in the 43758.5):

float m_rand(vec2 m_x) {
    return fract((cos(mod(dot(m_x, vec2(13.9898,8.141)), 3.14)) * 43758.5));
}

Raw GLSL after this PR (notice the improved precision, for example 43758.546875 instead of just 43758.5):

float m_rand(vec2 m_x) {
    return fract((cos(mod(dot(m_x, vec2(13.989800453186,8.14099979400635)), 3.14000010490417)) * 43758.546875));
}

Precision is very important for many use cases, for example that pretty famous (if not very portable) code snippet uses fract() to extract the float fractional part and preserving as much precision as possible is important here. Many existing GLSL / HLSL demos and tutorials currently suffer from this float literal precision loss when porting them to Godot, sometimes drastically, sometimes more subtly.

In many cases this PR slightly increases the length of each float literal in the final shader code, but the added size and parsing performance impact should still be very minor. If we want to be real resource misers with this, we could maybe try to limit the decimals to a smaller float precision (for example calling String::num(x, 10) etc. directly), but I don't think it's necessary. Also assuming that we don't want to support GLSL 4.0 style lf/LF double literals in the future.

This PR should not directly break backwards compatibility. However, this increased precision can change existing user shader code behavior, especially if people have already tweaked their code to work around this precision loss.

Generated noise values before this PR:

After this PR:

[clayjohn]

Looks good. For most numbers the generated string shouldn't be much longer anyway. And in those few cases where it is, we should definitely err on the side of having more decimals rather than fewer

[akien-mga]

Thanks!

[YuriSizov]

Cherry-picked for 4.1.1.