Add 64 bit Dir3 struct

[stevehello166]

Objective

When working with 64 bit numbers and transforms i would find it much more convenient if bevy natively had a 64 bit direction type. Therefore I added a 64 bit direction type.

Solution

Added a 64 bit direction type for 3d directions called DDir3. I was going to add one for Dir2, however, it would involve adding a 64 bit version of Rot2 which was out of the scope that I had intended for this PR.
I'm not entirely sold on the name DDir3, but it does follow glam's convention of 64bit structs being prefaced with D.

Testing

• Did you test these changes? If so, how?
  I added tests to the testing suite covering the new features added in this PR.
• Are there any parts that need more testing?
  Nope, not as far as I know.
• How can other people (reviewers) test your changes? Is there anything specific they need to know?
  currently the ddir3_slerp test fails with the following message and I haven't the faintest clue how to fix it.

thread 'direction::tests::ddir3_slerp' (32568) panicked at crates/bevy_math/src/direction.rs:1663:9:
assert_relative_eq!(DDir3::Z.slerp(DDir3::Y, 2.0 / 3.0), DDir3::from_xyz(0.0, 0.75f64.sqrt(), 0.5f64).unwrap())

   left  = DDir3(DVec3(0.0, 0.8660254037844384, 0.5))
   right = DDir3(DVec3(0.0, 0.8660254037844387, 0.5000000000000001))

• If relevant, what platforms did you test these changes on, and are there any important ones you can't test?
  64 bit Linux mint

[kfc35]

I know you mentioned this in the description of the pull request as something you’d like input on:
To deal with the floating point imprecision issue, you can just add an episilon argument to this assert like in the previous assert. From what I can tell from the test failure you put, it seems like the miniscule 0.0000000000000001 difference should probably be acceptable, right?
https://docs.rs/approx/latest/approx/

[kfc35]

I think, following the convention of assert_is_normalized, you probably need to add f64 appropriate abs and sqrt methods to ops.rs for std_ops_for_no_std and libm_ops_for_no_std and reference them here

I checked for you, and it should be pretty easy. For std_ops_for_no_std something like:

#[inline]
    pub fn abs64(x: f64) -> f64 {
        f64::abs(x)
    }

and

 #[inline]
    pub fn sqrt(x: f32) -> f32 {
        f64::sqrt(x)
    }

and the libm portion should be

#[inline]
    pub fn abs64(x: f64) -> f64 {
        libm::fabs(x)
    }

and

    #[inline]
    pub fn sqrt64(x: f64) -> f64 {
        libm::sqrt(x)
    }

With the correct comments and with the correct line indentations of course

[stevehello166]

If I'm adding these operators, should I just add 64bit equivalents for all the operators in ops.rs while I'm at it?

[kfc35]

Since they’re public facing utilities, you could, but I also want to be mindful of keeping the pull request scoped to your new struct. The other operations could be another pull request if you so choose / think it would be valuable to expose to others. I only think sqrt and abs 64-bit impls are necessary to have here since they can then be used by this assert function

[kfc35]

This alias should probably be updated to not conflict with the existing alias

DDirection3d with what seems to be what you’re going for

[kfc35]

Suggested change

	#[doc(alias = “DDirection3d")]
	#[doc(alias = "DDirection3d")]

Oops, I think somehow the double quote got weird with my previous suggestion, sorry about that!