Remove CoreStringNames and SceneStringNames

[AaronRecord]

See https://chat.godotengine.org/channel/scripting?msg=ZCRd86Xg7vAtDaNKu

Not certain that this is desired, but CoreStringNames and SceneStringNames aren't used very consistently, several of their StringNames are unused, and they're no longer that useful for caching the StringNames since we have the SNAME() macro. I this will make it less work to implement something better like godotengine/godot-proposals#2152.

[EricEzaM]

I think part of the idea was to prevent bugs caused spelling errors in the strings... although the StringNames classes were not really used very diligently or consistently throughout the codebase. What about SceneStringNames, should that be removed too? There may be others.

[AaronRecord]

I think part of the idea was to prevent bugs caused spelling errors in the strings... although the StringNames classes were not really used very diligently or consistently throughout the codebase

Didn't know about SceneStringNames, if CoreStringNames gets removed then it probably should too...
I like godotengine/godot-proposals#2152 better though, I think the signal names should be local to the class they originate from.

What about SceneStringNames, should that be removed too? There may be others.

From a quick search it seems SceneStringNames is the only other similar class.

[AaronRecord]

Alright, I removed SceneStringNames too... I was careful to not just do a simple regex replace, but to make sure that the strings actually matched what they were before (I used a regex to check for all StringNames that weren't the same as their variable name).

[akien-mga]

I think this may still make sense but would likely need to be redone.

But we should discuss it a bit more beforehand to make sure we agree on what should be done. SNAME() can in theory replace these classes but there's a valid point to make that it's not necessarily a gain to rely more on strings (and thus potential typos) instead of caching them in one location.

Back when this was discussed we also had some ideas to maybe use a macro that could define this kind of static StringName in the class with an actual C++ identifier so we avoid strings, but reduz wasn't fond of the idea IIRC.

It's not urgent for 4.0, this can be done after the 4.0 release as a general code quality measure.

[KoBeWi]

Related: #80573 and #81303
After the latter is merged, I plan to replace all strings with their singleton equivalents if available. The advantage of stringname singletons is that they allocate the name only once, which results in smaller binary size and faster initialization time (see #80573).

While the gain is rather minimal, it's still better to use them in place of repeated SNAMEs and plain strings. Though unused singleton names and names used once should be removed, I plan to clean up that too.

[akien-mga]

Superseded by #91909.