Natural dtype for rotation matrices

[asnt]

Tentative PR for #80

This could maybe be applied to other functions. I haven't checked yet. Any hints welcome.

[adamlwgriffiths]

I have a feeling those test failures are related to #77

[adamlwgriffiths]

I think any of the create_from_x functions would need this.
It may also be pertinent to add to the quaternion functions.

Lastly, update the CHANGELOG and add yourself to the contributors in the README if you wish =)

There are other features we need to include in the CHANGELOG since the last release, but don't let that stop you.

[adamlwgriffiths]

Anyone else want to chime in on this one? @foohyfooh?

[asnt]

I think any of the create_from_x functions would need this.

The other create_from_X functions from matrix33.py seem to behave as expected. The ones taking euler angles or quaternions as input rely on the fact that the input dtype is float, which is most of the time the case but not guaranteed (see below).

It may also be pertinent to add to the quaternion functions.

As for the creation of a rotation matrix from axis-angle, I would also enforce that Euler angles and quaternions be float. Currently, the create function for both representation uses the input dtype, which might be int in some cases (although that will probably only happen rarely since the values are usually passed as float).
Problematic cases:

>>> import pyrr
>>> e = pyrr.euler.create(1,2,3)
>>> e
array([1, 2, 3])
>>> e.dtype
dtype('int64')
>>> q = pyrr.quaternion.create(1,2,3,4)
>>> q
array([1, 2, 3, 4])
>>> q.dtype
dtype('int64')
>>>

Seems related to #35

[adamlwgriffiths]

That's the thing. If you want to enable user laziness, then you need to update all the interfaces to be more intelligent. So many API functions need to be touched.