Comparison traits for wide types not accessible on API

[dooost]

Currently the comparison traits CmpEq, CmpGt, CmpGe, CmpNe, CmpLt, CmpLe are not exported from the crate, which makes dealing with wide types inconvenient.

It's possible to add wide as a separate dependency and import the comparison traits, which is far from ideal. Considering the wide float types are re-exported from ultraviolet and are rather crucial to effectively using uv's own wide types, I think these traits should also be re-exported on ultraviolet's API.

Use of cmp_gt is also mentioned in the Ray-Sphere Intersection example on README.

[dooost]

If you don't see any concerns with this, I'd be more than happy to open a PR :)

[fu5ha]

Yeah these should probably be re-exported. Maybe in a prelude module or something, PR welcome :)

[dooost]

I had some time to have a look at this, and I'm having a bit of a hard time settling on a suitable module for these traits. Sorry in advance for the long-ish post, I'm fairly new to Rust and not super familiar yet with project structure common practices. :)
I think prelude kinda implies that use ultraviolet::prelude::* should give you a list of types and traits that would be used in majority of projects that use ultraviolet, but I'm not sure that's the case with these traits or f32x4/8. I would expect prelude to contain some vector and matrix types as well and generally the types you use most when using ultraviolet, but I think ultimately this would be a bigger and more complicated question, how should such a list can be curated so that wouldn't result in too many redundant imports when using use ultraviolet::prelude::*.
I considered a comparison module which felt a bit awkward as I'm not sure if there's anything else that could go there besides these traits.
Another idea was to create a wide module that would re-export f32x4/8 and also the comparison traits, but it might be misleading if the wide module do not contain the wide vector/matrix types. But I can see scenarios in which such a module would be useful, if it does include the wide vec/mat types too - however that would be a bigger re-structure and I'm not sure if that makes sense with the bigger picture of your plans for this crate.
Besides these, the simplest way of course would be to re-export these publicly from the crate root. (curently they're re-exported but with pub(crate)). While maybe not the most elegant solution, I can't really think of any downsides to this.

I'm wondering, what would you think would be the best course of action here?