Avoid deadlocks in multi-threaded management of the C# script map

[RandomShaper]

The idea here is that using a read-write locking instead of all-or-nothing reduces the chances of a deadlock.

I'm not sure if this covers every possibility of such, because the interaction between, say, multiple resource loading threads instantiating C# scripts and the .NET module can be complex. All I can say is that this at least stops me from being able to reproduce the issue with the MRP provided.

Note for reviewers: Disable whitespace diff as one of the methods has a change of indentation level that makes the patch look more complex than it actually is.

Fixes #99128.
Fixes #99839 (I haven't been able to reproduce the issue with the MRP, even after modifying it to effectively use multiple loader threads; however, it's extremely likely that the issue the reporter found is fixed by this PR).

[raulsntos]

Sorry for the delay. As discussed in RC, I believe this PR to be safer than #99798 and according to the author of the other PR it fixes their issue as well.

This PR changes the locking mechanism from lock(obj) to using a ReaderWriterLockSlim instance, reducing the chances of a deadlock. The other PR moves NativeFuncs.godotsharp_internal_reload_registered_script(scriptPtr) outside the lock, and while this also seems to avoid the deadlock it can cause regressions due to underlocking. So this PR seems safer.

I was unable to reproduce the linked issue, but the code looks good to me.

[akien-mga]

Thanks!

[conde2]

This didn't fix the issue in my end, any possibility to reopen the issue? Tested with the same MRP and still getting stuck when loading.