Should a Timeline's bounds reflect it's clock's bounds?

When looking into the issue causing https://github.com/CesiumGS/cesium/pull/12284/ I realized that the Timeline widget is not updating to reflect the start/end times of the clock it's linked to.

Similar the the Animation widget I would expect changing the `Clock`'s properties to immediately reflect and update the widget's view too.

In the issue linked above the clock is updated when the data source that's tracked is updated (in the `CesiumWidget`). The Animation widget reflects the current time. The Timeline reflects the current time because it's reflecting the clock's values, but the viewport/zoom was _not_ updated without the extra `timeline.zoomTo`

I would propose that `Timline.updateFromClock` should watch the `clock.startTime` and `clock.endTime` and reflect those into the `_startJulian` and `_endJulian` in the timeline itself.

The only issue that starts to make it weird is that the timeline can be zoomed and panned within the start/end times so if it was always zoomed to those every tick that functionality would be broken. It may also get complicated to know when to jump the timeline to a different range if the `Clock` values change etc.

@ggetz any thoughts on this?

Start with Timeline.updateFromClock and compare the Animation widget and CesiumWidget clock-update paths; review PR #12284 for the triggering scenario. Define how Clock startTime and endTime changes should affect _startJulian and _endJulian without breaking timeline zooming or panning, then verify the widget updates correctly when those values change.

Written by the indexing model from the issue text.