Math fixes

[connor-lennox]

Addresses several of the minor comments from my last PR.

A few of the changes mentioned there are not implemented here: namely the switch of the Point::Distance function (this is still an associated function taking in two references) and the shortening of Point calculation when pushing lines (subtracting a Vector from a Point gives a Vector, but adding a Vector to a Point gives a Point - this discrepancy is strange and how it is handled changes how things will be condensed).

[hannobraun]

Thank you, @connor-lennox, looks great!

I've left one comment where I noticed something that's not idea, but no big deal.

[hannobraun]

It's a bit unfortunate that we're going through a Vec here, due to the heap allocation that's probably expensive. I don't know how to change it off the top of my head, however. I'd have to experiment with it hands-on.

[connor-lennox]

I also wanted to avoid a Vec here. You can't collect an iterator into an array, though. One alternative way to implement this is to iterate over the slice elements and assign into some mutable array (not as pretty, but avoids the Vec)

[hannobraun]

Hmm, why not leave the code as it was before, with a slight modification:

let projection = Perspective3::new(aspect_ratio, fovy, znear, zfar);
let mut res = [0f64; 16];
res.copy_from_slice(
    (projection.to_projective() * self.0).matrix().as_slice(),
);
res.map(|f| Scalar::from(*f))

Should work?

But yeah, it's not that important. I'd be happy to merge a change that avoids the Vec, but I'm also fine with leaving it as-is.

[connor-lennox]

That would be a good way to avoid the Vec while still keeping things tidy. I don't think this will make or break the performance but it'll be good to keep in mind for later.

[hannobraun]

Agreed. No reason to bend over backwards right now. If there's really a problem, we can fix it.