Store Control constants as floats instead of integers

[Calinou]

This allows to store values like the editor scale in a constant. This way, we can eventually remove the need to include editor-only headers in source files in the scene/ folder.

The editor still appears to look correct, but please test for regressions anyway. I'd be surprised if everything worked as expected right now 🙂

[aaronfranke]

Perhaps double should be used instead, to allow for (reliable) integers higher than 16 million?

[Calinou]

@aaronfranke Maybe, but I can't think of what you'd need such large integers for in an UI context. The memory usage difference will probably be quite small and acceptable for 4.0, but I'd need approval from reduz first.

That said, scalar floats in GDScript are already 64-bit, so this would make custom constants consistent with them.

[TechnoPorg]

Is this PR still wanted, now that EDSCALE dependencies in scene (except for one in path_2d.cpp?) have been removed by #53341?

[YuriSizov]

In general, it would be useful to have constants other than integers. While using ints as booleans is normal for a programmer, it doesn't lead to a great user experience. Floats can be useful for several things as well. However, I suspect this PR needs to be redone at this point, rather than rebased.

[reduz]

I think editor scale probably should be accessible from the viewport/window, not from a theme property.

[Calinou]

I think editor scale probably should be accessible from the viewport/window, not from a theme property.

This was added in #53341.

I think float constants still have a few benefits, such as setting floating-point font sizes (even if the final rendering rounds them to integer sizes, at least for non-MSDF fonts). This gives you more control over a font's final size after oversampling.

[YuriSizov]

I think that ideally theme constants could allow any Variant constant, so bools would be true bools, and numbers can be both int and float, and maybe someone naughty would store something else in there.

[YuriSizov]

I think we can have a more flexible solution here, replacing ints with floats has a few downsides too. We should come up with a non-breaking solution during the 4.x development.