Part of the problem is the fuzzy line between `Clock` and `AnimationController`.  The clock knows "how fast" it's animating, and in which direction, but not whether it's paused or playing.  The AnimationController understands play/pause, and has API for forwards and backwards, but really the clock remembers whether we're going forwards or back.

The odd case of `_isOutOfRange` is mostly because I didn't have an event handy.  This could be replaced with an event, fired during the clock's `tick` to tell listeners that the tick moved the clock (or would have moved the clock) into a "paused" state, because the AnimationController needs to know about pause.  It's not something that can be queried, it really needs to happen as the result of a specific tick.

I'm still not sure we need to draw such a line between the clock and the animation controller, in my opinion there should be a single class that knows about current time, speed, and play/pause state.  Then a tick could directly trigger pause mode internally, and any resulting events would be for the benefit of client code, not Cesium internals.