Make everything generic wrt. the scalar type.

[sebcrozet]

As discussed in #53 cargo features should be additive, so using them as we do en nphysics might cause compilation-error related headaches for the user in case of simultaneous dependencies to, e.g., nphysics2d twice, once with and once without the f64 feature enabled. The simplest and most idiomatic fix here is to make everything generic wrt. the scalar type.

Fix #53.

[bluss]

😮 sorry for causing this. There's some positive sides with having non-generic code, but I guess that does not work out here. I can't think of a really nice way to have nphysics3d_f32 and ndphysics3d_f64 as separate crates.

[sebcrozet]

No worries! I prefer to keep compilation rules as simple as possible so that the user won't waste time because of some weirdness on nphysics feature requirements.

I always found this feature-based precision selection hacky-ish and ugly anyway. My main concern here is that making everything generic will increase compilation times of user code. But rustc made a lot of progress in that matter compared to, say, a year ago!

[bluss]

It's one of my recent discoveries too, that it can be much neater to have non-generic code. But I have failed to figure out to really make use of it in my projects where I have generic types. One thing you can watch out for is functions and types that are unnecessarily scoped under a type parameter without using it..

[sebcrozet]

Yes, as soon as you have generic types, everything tend to become generic as well. I a sense, Rust makes it so easy to write generic code cleanly that it is often very tempting to do so.

I'll try to get rid of any unneeded parametrization. Though I don't expect to find that many function on a math lib that does not has to be parametrized directly or indirectly by the scalar type! For the time being I'll merge this and see if users complain about compilation times.