Handle object destruction during Godot->Rust call

[Bromeon]

For RefCounted objects, user code can drop the last ref to itself mid-call (e.g. a signal handler nulling the emitter), which previously freed the storage under the active instance.

I did not go the route of GDScript to add a strong-ref to every Godot->Rust call, for multiple reasons:

• The problem of rugpulling the own instance still exists for manually managed objects. A panic makes it clear.
• The extra refcounts cost around ~40% overhead of an empty function call. This is a lot, considering that most Godot->Rust calls never face the rugpulling problem.
• There are still some edge cases that aren't even covered with the strong-ref approach (e.g. when refcount is already 0 during NOTIFICATION_PREDELETE)

Instead, the storage now counts "claims" on itself (Godot's + 1 per call on the stack), and is freed by whoever releases the last one. This is a bit more complex but retains the benefits of the old version.

Fixes #1666, now covered via itest signal_emitter_destroyed_during_own_call.

[GodotRust]

API docs are being generated and will be shortly available at: https://godot-rust.github.io/docs/gdext/pr-1671

[greenfox1505]

This prevents the full engine crash, but I still get this error message:

ERROR: Destroyed the Godot object during a Godot -> Rust call on it.
  The engine may access the object after the call returns, which is undefined behavior. Do not drop the last
  reference to an object inside a call on that same object; defer it past the call instead.
  object: Base { id: -9223372001454848550, class: InkVariableWatcher, refc: 0 }
   at: godot_core::storage::instance_storage::report_destruction_during_call (/home/greenfox/.cargo/git/checkouts/gdext-067f4b88e7bd088f/baa608c/godot-core/src/storage/instance_storage.rs:378)
   GDScript backtrace (most recent call first):
       [0] continue_story (res://addons/gdrs_ink/long_story_example.tscn::GDScript_l4es0:39)
       [1] choice_made (res://addons/gdrs_ink/long_story_example.tscn::GDScript_l4es0:70)

[Bromeon]

Yes, this is an upstream issue which I'm currently investigating. The error message makes it loud rather than obscure, but ideally we can address this in Godot itself.