Amethyst: [FEATURE MODIFICATION] Transform Euler rotation method name changes

[termhn]

Feature

Transform Euler angle rotation methods

Change

• Change roll_global -> rotate_z_global, yaw_global -> rotate_y_global, etc. for all local and global rotation methods. Alternatively, could follow rotate_euler_z_global etc. convention.

• Change documentation for set_rotation_euler method to remove references to 'roll', 'pitch', and 'yaw' in the parameter documentation, but note that nalgebra's set_euler_angles and euler_angles methods use 'roll', 'pitch', and 'yaw' with semantic difference from how Amethyst's transform is structured. (See associated PR for what this means exactly)

• Create our own euler_angles(&self) method on Transform which is documented to return rotation about X, Y, Z euler axes, and documents that the roll, pitch, yaw convention in nalgebra's euler_angles method uses "Z = up" convention, which is different than Amethyst which uses "Y = up".

Reason

nalgebra's methods related to euler angles use "roll", "pitch", and "yaw" semantics, but these semantics assume a Z-up coordinate system, while we use a Y-up coordinate system. I believe that the best way to fix this is to provide our own euler-angle related methods which only use axis semantics and not 'roll, pitch, yaw', and then to document the difference in nalgebra. This way we are not trying to override nalgebra's semantic 'roll, pitch, yaw' with our own, which I think would create even more confusion.

Another option would be to convert to just having a Z = up standard, but I believe that this is less common in game engines and computer graphics in general, and would mean needing to perform more conversions when rendering.

Additional Notes

Going to be creating a PR for my proposed version soon, but wanted to make an issue as there's room for debate on what the "correct" solution here is.

[termhn]

CC @jojolepro as I'm not sure how this would integrate with the new Transform restructuring.

[Moxinilian]

This year I had a physics class on coordinate systems, and my teacher referred to roll, pitch and yaw as based on the name of the axis. There seems to be diverging standards on that subject so I strongly advise we go away from such terms.

[jojolepro]

This change won't affect it, so its fine.

I'm also for avoiding pitch, roll and yaw. I didn't even know what they corresponded to up to a year ago, and once I knew, the different coordinate systems made those names confusing.

[ndarilek]

As the one who stumbled over this particular landmine, I also vote for using axis names, not roll/pitch/yaw, and I actually knew what they meant. :) There's already a bit of a cognitive load translating between Amethyst's coordinate system and the way I'm representing those coordinates to my players. If I decided to represent coordinates to players as Z-up, then having to translate roll/pitch/yaw to Amethyst's coordinate system and then to my player representation would be one step too much.