Repository: godot
Issue: `Variant::iter_get` on empty `Array` crashes in release, but no errors reported with `DEBUG_ENABLED`
Labels: bug,topic:core

### Tested versions

v4.3.stable.official [77dcf97d8]

### System information

 Godot v4.3.stable - Windows 10.0.22631 - Vulkan (Mobile) - dedicated NVIDIA GeForce GTX 980 Ti (NVIDIA; 32.0.15.6603) - 13th Gen Intel(R) Core(TM) i7-13700K (24 Threads)

### Issue description

Calling `Variant::iter_get` on an empty `Array` causes this crash, but only in builds without `DEBUG_ENABLED`. If `DEBUG_ENABLED`, no warning or error will be reported and an empty `Variant` will be returned.

```
Godot Engine v4.3.stable.official.77dcf97d8 - https://godotengine.org
Vulkan 1.3.289 - Forward Mobile - Using Device #0: NVIDIA - NVIDIA GeForce GTX 980 Ti

ERROR: FATAL: Index p_index = 0 is out of bounds (size() = 0).
   at: get (./core/templates/cowdata.h:205)
```

This appears to be because of these lines:
https://github.com/godotengine/godot/blob/0eadbdb5d0709e4e557e52377fa075d3e2f0ad1f/core/variant/variant_setget.cpp#L1807-L1927

Because editor builds always have the `DEBUG_ENABLED`, this crash will not reproduce with editor builds. Instead, this issue is more relevant to GDExtension or module projects, but I suspect it could also cause unexpected differences between debug templates and release templates as well.

### Solutions

At minimum, I would expect an error to be logged when `DEBUG_ENABLED`. If this causes too much error spam in the editor, which cannot be built without `DEBUG_ENABLED`, then this error could be silenced for editor builds.

Alternatively, these `DEBUG_ENABLED` segments could be changed to only apply to editor builds (changed to `TOOLS_ENABLED`), which would align debug behaviour with release behaviour. I have a preference towards this approach because I may not notice a rare error message during development, but then have the crash occur in a release build. This would leave me wondering why it never crashed during development, even though I tested it.

Whichever approach is taken, the important thing is that release build behaviour should be easy to reproduce or identify in a debug build. The current approach can result in a release mode crash when debug builds have no apparent issue.

### Other issues

From a quick glance at the source code, I suspect that this sort of pattern may be used elsewhere and other release-only crashes can occur because of the pattern.

### Steps to reproduce

Write the following code, say in a GDExtension using godot-cpp:

``` C++
Variant arrayAsVariant = Array();

Variant iterator;
bool iter_valid;
arrayAsVariant.iter_init(iterator, iter_valid);
Variant value = arrayAsVariant.iter_get(iterator, iter_valid);
```

Compile with `scons dev_build=yes` and note that there are no issues, warnings, or errors and `value` is `null`.

Compile with `scons target=template_release` and note the error and crash occur.

### Minimal reproduction project (MRP)

Here is an example GDExtension:
[release-only-gdextension-crash.zip](https://github.com/user-attachments/files/17949478/release-only-gdextension-crash.zip)

- Copy over godot-cpp 4.3 branch into godot-cpp folder
- Run both `scons dev_build=yes` and `scons target=template_release` to generate GDExtension DLL files
- Open the godot project in the `demo` folder
- Export both debug and release builds of the game 

Here is my compiler info:
`Using SCons-detected MSVC version 14.3, arch x86_64`

### Other discussion
This issue replaces godotengine/godot-cpp/issues/1652.