Re-enable num-traits under an optional feature

[althonos]

Hi Andrew!

First of all thanks a lot for developing this crate, I've been able to move some more of our data analysis pipeline to Rust thanks to it.

While I can understand why you want to get rid of the num-traits dependency in your context (at least, from what I got from the commit message of f19d626), it's actually super practical to have it available because you can depend on custom float types, the most interesting one for me being f16 from the half crate to work with a reduced memory footprint. The drop of num-traits support prevented me from updating to v0.3.

This PR keeps the best of both worlds by hiding the num-traits dependency behind a feature gate, which is disabled by default. Users like me who want to use the Float trait from num-traits can enable the feature, but by default kodama remains without dependency.

[BurntSushi]

Hmmm, I'm not so sure about this. What if Kodama's Float trait was instead unsealed? Then presumably you could implement it yourself?

[althonos]

I don't think I could, because f16 is also an external type, so I couldn't implement the Float trait from kodama. And given that f16 already implements Float from num-traits, that would actually require double the effort for something that is there already...

[BurntSushi]

Yeah the problem is that I'm just not sure I want to take on the extra burden of supporting num-traits optionally. I think the best I can offer is unsealing the Float trait. Then you can write a wrapper type that impls Float in this crate with anything that impls the corresponding trait in num-traits.

[althonos]

Ah, that's unfortunate. I thought this would be okay considering the trait was already implemented in the previous versions...