Optimize String construction from statically known strings by evaluating strlen at compile-time.

[Ivorforce]

In this PR, String constructors are now available which make use of known string lengths, avoiding a strlen call. For example, when using string literals like String s = "Test" it is knowable at compile-time that "Test" is a 4-length string. This is used to speed up String construction.

This PR builds on #99816. There, I have tested String construction from a long shader string literal, taken from the codebase. I ran the same benchmark to see how much known-length construction speeds up allocation:

• 335us on master (aa8d9b8)
• 139us on #99816 (e1c4239)
• 100us on this branch (10aac990e158592e2ed50b9dbeb513c7505128e2)

The speed-up is likely to be slightly better for short strings.

[hpvb]

LGTM

[Ivorforce]

I am deleting the StrRange constructors for now. They were not used yet in the PR anyway, and thus aren't relevant to it. Instead, I will make a follow-up PR to add factory methods with the same semantics instead of constructors, so it's clear how exactly the bits are treated.

[hpvb]

Still approved.

[kiroxas]

I would have used a more explicit uint64 type. No need to use uint32 as it will be padded anyway. So it will be clearer that every size is supported.

[Ivorforce]

You mean use uint64 instead of size_t? That would be fairly unusual when dealing with arrays.

[kiroxas]

Again, stylistic. But it removes ambiguity.
Unusual where ? CowData use uint64_t for its size, LocalVector uses uint32_t

[Ivorforce]

Interesting. I'm not sure why that is. Possibly because they're designed to be easily exposeable to GDScript?
Still, I think size_t is cleaner; it's very common to use that for sizes across c++.

[kiroxas]

I know that it is the default in C++ standard library. It's just, why be ambiguous on the size of a type when you don't have to. Size_t probably always is 64bits nowadays anyway, this is why this is a style choice. Any choice will do, just raising a point :).

[Ivorforce]

I'll keep it as size_t for now. But let's keep the discussion open for other people to chime in!

[Repiteo]

Style changes in core are inherently a very low priority, so I'm not too surprised there's mixing and matching of different names/formats. A lot of the discrepancies could come down to how several templates originally used int/32-bit storage logic instead of 64-bit, but I can't say for certain. In any case, size_t is perfectly acceptable, and is arguably the best option for logic/metrics having to deal with… Well, size!

[Ivorforce]

Sorry for repeated pushes, I accidentally pushed an old version and had to reset -.-

[Repiteo]

Thanks!