Degrade logging errors from ClassDB in some cases

[Ivorforce]

• Fixes Enum var, typing a period, ERROR Parameter "type" is null #117914
• Follow-up to Move enum registration from ClassDB / ClassInfo to GDType. #113586
• Follow-up to Move signal ownership from ClassDB to GDType #117474

As so often, I'm a bit over eager with printing on unexpected states.
This time, we get unexpected logs from autocompletion (#117914). While somewhat fishy to query ClassDB with classes that don't exist, it's not problematic and we didn't have logs before. So the agnostic thing would be to keep silently ignoring the invalid class name.

We can discuss re-adding those logs in the future. But that would need to be a more sweeping change.

[KoBeWi]

ClassDB has more errors for missing classes:

godot/core/object/class_db.cpp

Line 848 in 137fa73

ERR_FAIL_V_MSG(false, vformat("Cannot get class '%s'.", String(p_class)));

godot/core/object/class_db.cpp

Line 2031 in 137fa73

ERR_FAIL_NULL_V_MSG(ti, false, vformat("Cannot get class '%s'.", String(p_class)));

godot/core/object/class_db.cpp

Line 2039 in 137fa73

ERR_FAIL_NULL_V_MSG(ti, false, vformat("Cannot get class '%s'.", String(p_class)));

etc.

I think logging an error makes sense. Like, if you want to get constant list from a class, you expect that it returns that list. If you make a typo in class name and the method fails silently, you may spend much time troubleshooting wrong problem.
If we have code that checks for non-existent classes, if the error is a problem, that code should check if the class exists beforehand.

I'd change these errors to be consistent with the ones I linked above though.