UpdateList: reduce abstraction to aid debugging

[kkjamie]

Context

Right now the UpdateList is a generic thing that can update a series of update functions with the signature void Update(float dt).

Originally it was designed to be an abstract utility, but now since it lives inside the duck-tween library it now serves primary as the heartbeat of the animation system, used within the AnimationDrivers.

Problem

When something goes wrong it's quite difficult to debug since the update function only has an index to identify it, and theres no way to trace it back to which animation or target object it relates to.

Solution

Change the API to instead of taking update functions it can actually take a TimedAnimation and update that directly. Then if there is any issue we have the original object. For more flexibility we could introduce a new interface above it like IUpdateableAnimation or even IDrivableAnimation - to infer it's relationship to AnimationDriver - At that point I'd even consider renaming the update list so it's less abstract sounding and quite clearly the thing that's used within the animation drivers to invoke updates on the animations. The interface contract would require:

• void Update(float dt). If anything goes wrong we can ToString() the object, and in the implementation (TimedAnimation) we can have a nice ToString that contains the name of the animation and target object... maybe even the from/to/duration/easing properties.

There's even scope for having a scripting define for debugging where we capture a stack trace in the animation constructor and later that can be used to find out where the animation was constructed from.

Potential issues

Some projects maybe using UpdateList for their own purpose. Should these changes be implemented and should those projects wish to update to the latest duck-tween, the update list would not necessarily serve their purpose anyway. I think we shouldn't support that use case since it's strange to borrow from a tween library and grab that util for an entirely different purpose. It may still work if they can just update to implement our new interface, but it still wouldn't necessarily make sense.