Fix RemoteTransform3D to always use global rotation if use_global_coordinates is true

[TheSofox]

Fixes #97470.

RemoteTransform3D would sometimes update the rotation of its target object according to local coordinates even when use_global_coordinates was true. This PR fixes that.

Incidentally, if the settings to update Scale Position and Rotation were all true, this bug wouldn't be triggered.

[KoBeWi]

Seems like scale has the same problem, i.e. it's not global.

[TheSofox]

Got weird behaviour when I tried to switch Scale to global too. Rather than dig in, I just decided to go with the Global Rotation fix which I was sure worked.

[akien-mga]

CC @MajorMcDoom to confirm this works for your use case.

I'd also like some input from mathy contributors, it seems weird to me to use global rotation but not global scale, but I'm not too up-to-date on the intricacies of successive matrix operations.

This should also be compared with RemoteTransform2D to make sure the logic is consistent (there it seems to handle rotation differently by starting from the transform to sync with).

[MajorMcDoom]

CC @MajorMcDoom to confirm this works for your use case.

I'll check in a bit.

I'd also like some input from mathy contributors, it seems weird to me to use global rotation but not global scale, but I'm not too up-to-date on the intricacies of successive matrix operations.

It definitely is weird to use local scale when global is enabled, especially since global scale is used when all the properties are true. So there's some weird inconsistency there in the behaviour. You can get into a situation where simply enabling position syncing will make the global scale work properly, which is quite odd. I do understand the challenges though, since the meaning of "global scale" becomes a little open to interpretation when you disable rotation syncing, but we definitely need a better solution than now. It could also use a bit of optimizing.

[MajorMcDoom]

@akien-mga
UPDATE:
Confirmed that this PR does fix the specific issue in #97470

[MajorMcDoom]

After taking a closer look, I did another take here: #102223, which attempts to fix all the space-related issues in one go, plus some optimizations. (It couldn't be done as an additional step to this PR - it completely restructures the code and calls different methods).

Of course, we could still go with this smaller, more targeted fix if it feels safer.