AtmosphereLayer should react to its time property about webworldwind

[zglueck]

I agree with @AkeluX assessment, utilizing the time property when available is logical and can be done in a way which still allows the explicit position definition using the lightLocation property. The inconsistency between light position definition is highlighted in the Starfield.js example. The StarfieldLayer and AtmosphereLayer are both environment layers and a common property interface (not necessarily inheritance based) makes sense.

I've implemented an initial approach in the branch: feature/#100-atmosphere-time for discussion and review.

[pdavidc]

@AkeluX and @zglueck we're in agreement that the time property will be the primary mechanism for defining the sun location for both AtmosphereLayer and StarFieldLayer. Also, @zglueck has shown that the changes are straightforward to implement.

That said, I have a reservation about lightLocation and I think we ought to remove it. It exists as a stopgap measure before automatic sun location was available. Although I can easily imagine the use case @AkeluX describes, there isn't a real need for this capability that I'm aware of. The complexity introduced by the interaction between time and lightLocation then seems more trouble than benefit.

Should a real use case arise, my experience has been that it's almost always slightly different than we imagined. By leaving this interface in now, we may find our options unnecessarily limited in the future.

[pdavidc]

@zglueck I've discussed this with @AkeluX. We will remove lightLocation, with the expectation to reintroduce it, or something like it, should a real use case come up.

[zglueck]

@pdavidc @AkeluX I've got the changes pushed, I'm working on the pull request. Should be available shortly.