Fix existing implementation issues with the Track

[MakoEnergy]

The current Track class suffers from a few issues:

1. Most of the interpolators lack tests of them being used in conjunction with the Track.
2. Rotations are not being properly handled. SLerp and NLerp are desirable for handling rotations.

Some extra notes about these issues:

1. It is not currently clear that SLerp and/or NLerp can be written in a generic way as an interpolator class.
2. Even if they could, handling a compound class (such as a Transform) couldn't be handled if we take that approach with the existing Track design.
3. Other approaches involve defeating the existing design to one extent or another. Such as writing an "InterpolationTraits" class for each math type we want to interpolate.

A simple test of the Track exists in EngineDemo, where translations are being handled appropriately with the LinearInterpolator, but rotations are going 3/4ths the way and then reversing, due to the algorithm used assuming a reverse direction is the fastest path back to origin. There are also some assumptions being made in respect to adding Quaternions, which does not produce a concatenation of two Quaternions like it does with Vectors.

A vaguely related issue: #73

[MakoEnergy]

Some additional links for research purposes:
https://en.wikipedia.org/wiki/Slerp
https://keithmaggio.wordpress.com/2011/02/15/math-magician-lerp-slerp-and-nlerp/
https://stackoverflow.com/questions/2708476/rotation-interpolation