[3.x] Use hash table for GDScript parsing

[lawnjelly]

GDScript now uses hash table for lookup of type lists / functions / keywords, instead of linear String comparisons.

Helps fix #74733

HashTable lookup during parsing seems approx 20x faster than linear search.

Notes

• Profiling reveals after the other fixes, looking up keywords / functions using a linear search with lots of String == comparisons is very slow, this is better suited to a hash table.
• I'm not super familiar with the parser so this could do with double checking by GDScript guy.
• Using an OAHashMap here, welcome suggestions if there is a better container, can be slow insertion but needs fast lookup.
• Using dynamic allocation just to be super safe - reduz mentioned previously that some of the Variant / possibly String stuff might not be safe to store as globals due to order of construction / destruction.
  I couldn't immediately see a good place to put them as member variables (GDScriptTokenizer gets reconstructed often so not a good candidate, as we want to set up the hash table only once), but would welcome any suggestions.

[vnen]

I haven't really worked with this code in quite a long time. For what I can assess it looks good.

[vnen]

BTW the tokenizer in 4.0 is still doing string comparisons but it has optimizations of its own. It only cares about keywords (built-in types and functions are seen as regular identifiers), it checks for length first (ids shorter or longer than any existing keyword skips the checks), and it's grouped by first character (only if the first matches it checks for keywords in the group, which has at most 4 items currently).

I haven't profiled it so I'm not sure if a hash table would be faster or worth the extra memory.

[lawnjelly]

BTW the tokenizer in 4.0 is still doing string comparisons but it has optimizations of its own. It only cares about keywords (built-in types and functions are seen as regular identifiers), it checks for length first (ids shorter or longer than any existing keyword skips the checks), and it's grouped by first character (only if the first matches it checks for keywords in the group, which has at most 4 items currently).

I haven't profiled it so I'm not sure if a hash table would be faster or worth the extra memory.

That sounds pretty good for 4.0. 👍 🙂
The main win I think is having something better than a linear search, but it might be interesting to compare at some point.

[akien-mga]

Thanks!