Add custom data types for angles and factors/percentages

[Keavon]

Instead of using f64 for all types of numbers, there are some with special significance.

• Angles can be represented by degrees or radians. Our data type should encode one unambiguous value, enforcing any nodes that want to construct or read an angle to do so with an explicit choice of degrees or radians. This should replace the Transform node's rotation and X-skew/Y-skew angles, avoiding the confusion that the inputs given in the node graph aren't the user-friendly degrees set in the Properties panel. (See #2431)
• Percentages can be represented out of 100 (percent) or 1 (factor). This distinctly represents not a quantity but a portion out of a whole, so it needs its own type. This avoids the confusion and mess caused by our current inconsistent usage of percentages and factors in various places, with uncertainty about whether those values are out of 1 or 100 when fed by the node graph. We can ensure number input widgets in range mode display the factor or percent on a per-case basis for whichever is designed to be the more logical approach, or do what Blender does and offer an app preference to display all such quantities as out of 1.00 or out of 100%.

[Nirajsah]

@Keavon Just to confirm before starting work: In a node like Transform, fields such as rotation and skew currently display in degrees by default. But under the hood, I assume the math is being done in radians. Would it make sense to add a dropdown that allows users to choose between degrees and radians? And accordingly update the node type to handle this conversion explicitly?

[Keavon]

@Nirajsah all user input values should be in degrees and the angle type described in this issue should also be stored in degrees to avoid the numerical imprecision of a roundtrip multiplication then division by tau.

[Nirajsah]

@Nirajsah all user input values should be in degrees and the angle type described in this issue should also be stored in degrees to avoid the numerical imprecision of a roundtrip multiplication then division by tau.

as far as I can understand, degrees -> radian -> degrees, currently this is how its working.
not to have f64 imprecision, we only want to deal with degrees.
currently I am looking at transformation.rs which has TransformOperation and TransformType.
are there other nodes other than Transform node which need the Angle Type?

[Keavon]

I recommend re-reading the issue description and beginning with percentages instead of angles.

[Nirajsah]

I recommend re-reading the issue description and beginning with percentages instead of angles.

I understand that the math is done in radians and not in degrees — I was just trying to understand how things work. I'm not suggesting replacing radians with degrees. I understand that the issue is about introducing an Angle type to classify between degrees and radians for clarity.

You mentioned imprecision earlier, so I thought maybe you were referring to using degrees instead of radians to avoid round-trip errors — which is why I asked. Thanks for clarifying.