[DRAFT] GDExtension: Fix crash by copying GDExtensionScriptInstanceInfo2 on the Godot side

[dsnopek]

Fixes a crash that was introduced in PR #78634

Previously, Godot was keeping a pointer to the GDExtensionScriptInstanceInfo or GDExtensionScriptInstanceInfo2 created on the GDExtension side. The crash is caused because we provided compatibility by copying the data from provided a GDExtensionScriptInstanceInfo into a new GDExtensionScriptInstanceInfo2 on the stack, which is, of course, temporary. We could certainly allocate a new GDExtensionScriptInstanceInfo2 on the heap, but then we need to keep track of whether it was created on the GDExtension side or the Godot side so we know if we should free it or not.

This PR side steps that whole problem by instead making a copy of the struct on the Godot side, which we should probably do anyway, so that the GDExtension can't accidentally modify or free the struct on its side.

This is currently marked as a draft because I haven't had a chance to test it yet!

[dsnopek]

@maiself brought up over on #78634 (comment) that this is copying this struct once per script instance which means each instance will take up 23 pointers more memory (92 or 184 bytes depending if it's a 32-bit or 64-bit architecture). That's not ideal...

So, perhaps this will remain a draft until we can figure out if there's a better solution.

[dsnopek]

So, originally, I didn't like the idea of having the compatibility function allocate a new GDExtensionScriptInstanceInfo2 on the heap (and then, I guess, set a bool on ScriptInstanceExtension to tell it to free it at the end). But thinking about it some more now, that would mean that only GDExtensions using the compatibility function are hit with the extra copy and memory allocation, whereas GDExtensions using the new function keep working basically the same as they did before.

Maybe that is a better way afterall?

[maiself]

Tested this, fixes all crashing I was seeing.

[dsnopek]

@maiself Thanks for testing!

[dsnopek]

PR #81206 has an alternative approach in line with my previous comment

[Sauermann]

I'm inclined to find #81206 a better approach than this.

[dsnopek]

Superseded by #81206