Fix dangling Variants (3.2)

[RandomShaper]

This commit addresses multiple issues with Variants that point to an Object which is later released, when it's tried to be accessed again.

Formerly, while running on the debugger the system would check if the instance id was still valid to print warnings or return special values. Some cases weren't being warned about whatsoever. Moreover, on release builds you would experiment undefined behavior; specially, crashes.

Also, a newly allocated Object could happen to be allocated at the same memory address of an old one, making cases of use hard to find and having Variants pointing to the old one magically reassigned to the new.

This commit fixes all these problems:

• While debugging you still have instance id checks so you get warnings about trying to operate on objects that have been already released.
• But the debug behavior on those cases is now consistent: aside from returning the most reasonable value in read operations given the circumstances, you get a printed warning in all cases and with an easier to understand message.
  - On release builds, the instance id check is not performed, so no warnings are printed, but now the validity of the Variant is checked by more optimal means, allowing the system to act in a controlled manner in those cases, as if it was null, with no crashes, etc.
  UPDATE: This PR has been updated to remove the checks from release builds. A separate proposal about how to include them for those needing maximum safety will be written, so don't worry. What is done in this PR is already good stuff.

All that said, in the name of performance there's still one possible case of undefined behavior: in multithreaded scripts there would be a race condition between a thread freeing an Object and another one trying to operate on it. The latter may not realize the Object has been freed soon enough. But that's a case of bad scripting that was never supported anyway.

---

Part of the credit for this goes to @reduz, since this is the result of implementing an approach he suggested to me with some additional ideas of mine.

---

This code is generously donated by IMVU.

[akien-mga]

Thanks!

[akien-mga]

@godotengine/bugsquad This likely fixes many open issues about Variant references being wrongly reassigned to a random node after free. Feel free to hunt them down and close them as fix (another fix for that issue was already merged in master a while ago).

[oeleo1]

That's great! Thanks for fixing this critical issue. What's the plan for release builds in 3.x ? Currently we're bound to debug builds since our release builds crash systematically. I couldn't find the mentioned new proposal for that, so could you please provide the link if it exists? Thanks!

[RandomShaper]

I haven't had time yet, but I'll give it a higher priority in my backlog.

[oeleo1]

As far as I can tell, there's not much we can do as users in GDscript to avoid the issue, or is there? We don't use threads, but we do use audio which is multi-threaded under the hood. Unfortunately release builds currently seem to be trading safety for speed which is unfortunate and prohibitive. Since safety prevails, we're stuck to debug builds with the assumed cost of lower fps.