Move logic for real-time mode (SYSTEM_CLOCK) into Clock itself.

[shunter]

SYSTEM_CLOCK implies animating forward at a 1x multiplier. Centralize the logic for dealing with coordinating clock settings in Clock itself. When switching to SYSTEM_CLOCK, other values are immediately updated to be consistent. When changing other values, e.g. current time or multiplier, SYSTEM_CLOCK is deactivated.

This fixes some inconsistencies in the UI where the logic was not consistent, due to being scattered around. Specifically, when you dragged the timeline while in realtime mode, you ended up in a hybrid state where the mode was still set to SYSTEM_CLOCK and therefore the label in the UI still said "Today" etc.

[mramato]

I'm getting a test failure for Widgets/Viewer/Viewer updates the clock when the data source changes

[shunter]

Fixed.

[shunter]

One thing I noticed while looking at DataSourceClock is that it blindly copies all values from itself into the Clock instance, but a default-constructed DataSourceClock has undefined values for all settings, which would corrupt the clock I believe. Now fortunately the CzmlDataSource and KmlDataSource make sure to set all the properties no matter what, otherwise it would wreck everything, but should the getValue be smarter about checking for undefined values and not changing the Clock?

[mramato]

Now fortunately the CzmlDataSource and KmlDataSource make sure to set all the properties no matter what, otherwise it would wreck everything, but should the getValue be smarter about checking for undefined values and not changing the Clock?

We certainly shouldn't put the clock in an invalid state. Feel free to open another PR with DataSourceClock changes. That code is really old and used to be specific to CZML, so it probably just evolved outside of its original expected usage.