Make ClassDB::classes pointer-stable again by changing it to HashMap

[Ivorforce]

• Alternative to Fix ClassDB crash caused by HashMap reallocation invalidating parent_ptr #1886
• Should fix ClassDB AHashMap segmentation fault #1884
• Should fix Editor crashes when calling virtual functions from classes that inherit from abstract classes #1873
• Should fix SIGSEGV in AHashMap::_lookup_pos_with_hash on deep inheritance chains containing an abstract class after commit 2fd41b7 #1862
• Fixes regression from Replace unordered_map with AHashMap to improve build time #1839

I'm not sure why I haven't thought of this problem when suggesting to use AHashMap for #1839, or noticed it on any of the issues that popped up. That was a blunder on my part. Sorry, folks!

The problem materializes (in potentially various semi-related ways) as soon as at least ~13 classes are registered.

Explanation

ClassDB::classes holds ClassInfo densely. That means that on every resize, the ClassInfo structs move in memory, which makes pointers to them illegal.
@SiimonDev correctly identified this as a source of failure, and in #1886 fixes some issues by removing pointers to the ClassInfo structs.
However, I think it is expected that the ClassInfo structs have stable locations in memory. Not being able to hold pointers to it could be a significant performance burden.

Stable memory locations could be accomplished by either using HashMap (see pointer stability in Core types), like Godot (https://github.com/godotengine/godot/blob/9dd6c4dbac70b28e8156255c3a2b78722772b036/core/object/class_db.h#L204), or by changing it to hold ClassInfo * (like the current state of godotengine/godot#106646).
I'm not fully convinced of the benefits of using AHashMap when we're using allocations with values anyway, which is why I'm hesitant to merge godotengine/godot#106646 right now. So that's why Godot upstream is still using HashMap.

Long story short, HashMap guarantees pointer stability, which should fix the problem.

[dsnopek]

Thanks!

[SiimonDev]

Nice, thank you!

[Ivorforce]

I wasn't able to reproduce a crash with 35 classes (I suspect memory keeps being allocated inside the same page as the previous AHashMap buffers), would probably need even more classes / memory churn in between registering to trigger it), but I was able to confirm that parent_ptr was incorrect after registering too many classes with the following:

	print_line("===========================");
	for (auto &info : classes) {
		print_line(info.value.name);
		print_line((uint64_t)&info.value);
		print_line("--" + String::num_int64((uint64_t)info.value.parent_ptr));
	}
	print_line("===========================");

(printing old / outdated pointers for parent_ptr that don't appear in the values themselves).
Cherry-picking 788edc6 (this PR) fixes this issue.

[SiimonDev]

Might be redundant but I tested this in my project where AHashMap would crash previously. This commit however ran without any issues. Thank you very much!

[dsnopek]

Cherry-picked for 4.4 in PR #1890

[dsnopek]

Cherry-picked for 4.5 in PR #1891