Reduce cross project includes by rewriting HashMapHasherDefault.

[Ivorforce]

• Helps address [TRACKER] Compile time issues caused by excessive includes #111218

Godot is plagued by long compile times because of unnecessary cross project includes.
Two of the main culprits in Core are hashfuncs.h and variant.h.
This PR eliminates cross project includes from hashfuncs.h, to improve compile time and reduce type coupling.

Explanation

HashMapHasherDefault was previously written by implementing a static uint32_t hash(const T &) function for every known Variant type. As Variant types grew, so did the includes for hashfuncs.h.

I rewrote the struct by adding a type trait called HashMapHasherDefaultImpl<T>. This type trait can be declared for any type, providing a hash function for default hashing, analogous to HashMapComparatorDefault.

The type trait is specialized for primitives (like double and int32_t).
It is further specialized for enum types by using the underlying type, which was also the previous behavior (through implicit conversion).

It is also specialized for types that declare uint32_t hash() const;, by calling this function. This behavior was previously implemented with HashableHasher, whose implementation claimed it is only possible to generalize this with c++20 concepts. I removed the now unnecessary HashableHasher type.
Using this specialization, hash functions are moved to the appropriate types. By this move, the includes from hashfuncs.h could be removed.

The same trick was applied to HashMapDefaultComparator, which previously had unnecessary specializations that all called is_same. I generalized this assumption with type trait logic (SFINAE).

Side effects

• Color was previously hashed by converting to String and hashing the string (through implicit conversion). This was slow. I optimized the conversion to hash with the components instead.
• hash_map previously needed a Variant include because it declared a function that assumed Variant keys. I generalized the function to use a comparator, and moved the variant comparison method to dictionary.cpp (the only place where it was used). This allowed me to delete hash_map.cpp.
• It is no longer possible to "auto-declare" hashing functions by declaring an implicit conversion operator. This is sane, especially since we have many lossy and slow implicit conversion operators in the codebase (as seen on Color). Two types now need to define an explicit hashing function that did not need to declare it before.
• It is now possible to hash enum struct, which was not possible before. Previously, the enum needed to be implicitly convertible to its underlying type, to support being hashed by HashMapHasherDefault.
• I had a problem with ImageLoaderSVG remotely, to debug it I inserted the error code to the error message. It seems to have mysteriously disappeared, but I'd argue having the error code for the future is good anyway.

[YYF233333]

I've done some experiments and unfortunately this PR alone doesn't reduce build time, because all the headers removed from hashfuncs.h are still included in variant.h, and hashfuncs.h is almost always indirectly included via variant.h. So in practice, the number of headers processed by each translation unit hasn't decreased (But anyway, this is a good start ❤️). I tried cleaning up variant.h, but ran into some tricky issues (mostly caused by Callable). I think this is a good opportunity to revisit #105254, #105231, and #104627, as those PRs should help address some of these problems.

[Ivorforce]

I've done some experiments and unfortunately this PR alone doesn't reduce build time, because all the headers removed from hashfuncs.h are still included in variant.h, and hashfuncs.h is almost always indirectly included via variant.h. So in practice, the number of headers processed by each translation unit hasn't decreased. I tried cleaning up variant.h, but ran into some tricky issues (mostly caused by Callable). I think this is a good opportunity to revisit #105254, #105231, and #104627, as those PRs should help address some of these problems.

Thanks for checking! I was guessing as much, for the same reasons you mentioned; almost everything ends up including variant.h anyway. Still, we'll need to resolve includes in both headers (variant.h and hashfuncs.h) to finally untangle this mess, so we might as well move forwards with this one now.

[Repiteo]

This should probably be made into a hash function within the Pair template itself. Failing that, the type should be forward-declared.

[Ivorforce]

This is one of those cases where it really depends on perspective of which is the more 'fundamental' header. If it is hashfuncs, the functions should be declared on Pair. If it's Pair, they should be declared on hashfuncs. I deem Pair to be more fundamental.
That being said, forward-declaring Pair is much better than including it!

[Repiteo]

Great work!

[Repiteo]

Thanks!