Bivector and Rotor

[kvark]

Fixes #32

There is a few issues I'd like us to resolve before we settle on something:

1. dimensionality: does it make sense to have Bivector3 instead of Bivector here, and similarly for Rotor?
   • there is hardly any use for other dimensions, hence I think we can avoid the number suffixes
2. notation: is xy/xz/yz the only used notation for bi-vectors? How should rotor fields be called? The current "s" and "b" are just random, basically.
3. consistency with quaternions: does anything need to be done about the fact that the vector part of a quaternion has the type of Vector3? It isn't really a vector, much closer to bi-vector, in which case people just need to use Rotor anyway. Perhaps, the Quaternion type shouldn't be written in the vector form at all to avoid confusion.

[kvark]

r? @nical @Ralith

[Ralith]

does it make sense to have Bivector3 instead of Bivector here, and similarly for Rotor?

There's definitely a case for a Rotor2: 2D rotations that have singular representations and well-defined precision are nice. nalgebra already has the very similar UnitComplex type for this exact reason.

I'm less sure of the usefulness of a Bivector2. If mint might ever support dimensionalities > 3, consistency wouldn't hurt.

consistency with quaternions

I'm not sure what "much closer to" means. It does seem like it might have been best to define quaternions with s/i/j/k members. Not sure that's worth breaking compatibility.

[aloucks]

Can we put the scalar at the end of Rotor to match the updated Quaternion

Related: #50