Fix method hashes with default arguments

[dsnopek]

Fixes #81386

Here's the start of a fix for the incorrect method hashing from issue #81386, including a mapping system so we don't have to break compatibility.

This is a draft because I haven't added any of the mappings yet (still working on a script to do it), but I wanted to start trying this on CI right away.

UPDATE: The list of mappings are in now, but they're missing a couple. Just need to get the CI passing to take this out of draft.

[pkdawson]

There are two methods which have DEFVALs but no actual arguments. Those are DirAccess::list_dir_begin and DisplayServer::is_touchscreen_available.

If we want to avoid changing those hashes, I would suggest simply:

for (const Variant &v : get_default_arguments()) {
	hash = hash_murmur3_one_32(v.hash(), hash);
}

[dsnopek]

Hm. We probably shouldn't be including default arguments that aren't paired with actual arguments in the hash in the first place. And since we're already doing a mapping here, this actually seems like a good time to break those hashes. :-)

Locally, I tested removing the invalid default arguments, and the hashes (with the new calculation in this PR) remained stable, which I think is what we want. So, we can delete those DEFVAL()s at anytime, and if anyone adds any default arguments without arguments in the future, they won't be counted.

[dsnopek]

This is ready for review! Tests haven't finished running yet, but everything seems good locally, so I'm expecting them to pass.

It now includes the full hash mapping, mostly generated via a script that compared the extension_api.json before and after changing the hash calculation. There were, unexpectedly, a few that I had to do by hand: where there was a pre-existing compatibility method, and the hash of the compatibility method would change too.

[RedworkDE]

Generally looks good to me, but I didn't test the code.

[Bromeon]

Thanks for addressing this! 👍

[Bromeon]

General question: with DISABLE_DEPRECATED, do we still write this key?
Might very well be "yes", just wanted to double-check 🙂

[dsnopek]

Hm, well, if all compatibility methods are also wrapped with #ifdef DISABLE_DEPRECATED then we won't have anything else to put into "hash_compatibility". But I think this is fine? The idea of compatibility hashes still exists with DISABLE_DEPRECATED, we just aren't registering any.

[BastiaanOlij]

Reviewed during GDExtension meeting, this looks like a good way to solve the backwards compatibility issue, much better then introducing 800 compatibility calls :)

[akien-mga]

Thanks!