Possible race condition in `Skeleton` handling

### Tested versions

4.2.1

### System information

Windows 10/11, Godot 4.2.1, Gles3 compatibility

### Issue description

I have multiple crash dumps from users where the game segfaults somewhere deep in the GPU driver. Most of these are from AMD users but I also got a couple from Nvidia GPUs so this doesn't seem to be vendor related. I am also not 100% sure all of them are using GLES3 but reasonably certain. What I can however see, is that in all crash dumps the godot main thread is currently manipulating `Skeleton3D`, Either in `Skeleton3D::_notification` with `NOTIFICATION_UPDATE_SKELETON` or in `GLES3::MeshStorage::_update_dirty_skeletons`.

### Steps to reproduce

No idea, I guess trying to rapidly modify Skeleton3D might work but I wasn't able to reproduce this issue so far. I have attached the only model with a skeleton that we are using.

Main thread:

Crashed thread:

Exception:

Main thread from a different dump (driver call stack was identical):

### Minimal reproduction project (MRP)

[robot.zip](https://github.com/godotengine/godot/files/14423031/robot.zip)

Start with the reported call sites, Skeleton3D::_notification with NOTIFICATION_UPDATE_SKELETON and GLES3::MeshStorage::_update_dirty_skeletons, then inspect robot.zip and the attached crash information. A useful result would require determining whether concurrent Skeleton3D manipulation causes the driver crashes, although the report currently has no reproduction steps.

Written by the indexing model from the issue text.