First-class support for a degree based workflow

If one wants to specify and read angles as degrees, it seems like one is out of luck with this package. Of course, one can always do

RotXYZ(deg2rad(10), deg2rad(20), deg2rad(30)) = RotXYZ(deg2rad.((10, 20, 30))...)

or

import Unitful: °
RotXYZ(10°, 20°, 30°)

While the first options are not terrible, I am not a fan. As for unitful, I do not like having to import a new package for simple conversion. And neither option solves printing as degrees.

Personally, I would love to have variants of the different representations that have a lowercase "d" appended, similar to sin and sind. So we would have RotAd, RotABd, RotABCd, AngleAxisd, and whatever other representations that take angles as input. These representation could store the input as degrees, and dispatch to e.g. sind instead of sin, and in that way close #196 and #197. They could also print those stored fields as degrees, without floating point conversions between radians. All in all I think it could be quite neat, for both exactness and to make a degree-based workflow feel first-class.

No file or test is named. Start by reviewing the existing rotation representations such as RotXYZ, RotABC, and AngleAxis, then read issues #196 and #197 for related degree behavior. Done would require an agreed set of degree-based variants, degree-preserving storage and printing, and degree-aware trigonometric dispatch.