Implement a general mechanism for detecting typos in symbols

[NathanLovato]

There are some words in particular that learners struggle with typing, and the generic "not found in base self" message is not good enough for them.

This task is about adding a way to detect typos and symbols and suggest a correction instead of falling back on the generic compiler error.

This is something to test in particular in exercises like L4.P3, for example, with the move forward function, a lot of people omit an R or something like that. I would like them to get an error message like "You wrote move_foward, which does not exist, did you mean move_forward?" highlighting the differences like this if possible, but even if not, it's okay.

I don't know if this is something that should be automatic or based on the symbols we register in the documentation. There's some decision to make here, so don't hesitate to ping me to discuss that. I just know that this is a problem we want to address in more than a single specific case.

There are related specific problems where I would like a more specialized message. For example, people may often type vector2 instead of Vector2. In this case, I would like to be able to explain them specifically about this Vector2 value type that is specific to Godot.

[Razoric480]

At the moment there's no mechanism for adding an explanation button or specialized message as you mention for e.g. Vector2, but it should at least catch typoes that have a 65%+ confidence rating (adjustable.)

See _find_similar in UIPractice.

It plumbs the depths of ClassDB, GDClassNode,the base Scripts themselves (e.g. DrawingTurtle), and a custom Builtins for @GlobalScope and @GDscript, to get its symbol information.

It's always possible it'll get some false positives if the typoes are just confusing enough but not egregrious enough to just not have any ideas. It uses String::similarity.

[NathanLovato]

Thank you. That looks good to me. The only comment I have is on the way the _report_possible_typoes() function extracts from error messages. I would avoid substrings with specific indices because these error messages is something that is not classified or stable in Godot and that can/will move from under our feet in the future (See how messages, including for the same errors, changed between version 3 and 4).

This is also an area where generally I'd like to add to our test suite, having some code that triggers the expected error and verifies that the message is what we expect for these few messages that we really want to rely on. Not necessarily for every error, but for example, this specific part of the code is one that's easy to lose track of, I think.