[Request] Unify .step overloads.

[loganmcbroom]

I think overloading a function for integral and floating point types and having the meaning of the function largely change based on that overload is a recipe for disaster. Reading t.step(a/b), it is not clear what the code does without knowing the types of both a and b. Especially in c++ with our glorious implicit type conversions, seemingly innocent changes can break the library.

More generally, I think this library could be largely improved by not trying to track time via both integral variables and a floating point percentage. I'm guessing there is some underlying benefit to this design that I do not know without inspecting internals, but it has caused me to make several errors.

Finally, I would update the manual code snippet tween.step(dt);, as dt is not a percentage.

[mobius3]

Makes sense, but I still see the usefulness of stepping by the percentage and I don't know what to call it... I've been thinking about helper types for this, to be clear about what is going on, so it would be

t.step(duration(12)) for 12 duration "steps" and t.step(percent(10)) for 10 percent stepping. What do you think?

[loganmcbroom]

Personally, I would have t.step always step by time and add a stepPercent method to step by percentages. Enforcing units with types could be helpful though, for more explicitly showing what time unit is being used, e.g. .during(ms(300)). With that in place, if the internals require integral time units, they could consistently be stored in something like nanoseconds. That would also allow using seconds as a unit (I find this not being an option odd), though it would require switching the 16 bit integer types used to 32 bit.