## Motivation
On evaluating clock for the first time it was equal to zero
## Changes
Observing `_displayLink` I noticed that for the first time when it's being set, the value of `_displayLink.timestamp` (and `_displayLink.targetTimestamp` as well) was equal zero from some unknown reason.
However, I have found it pointless to look for bug here and actually cannot see why it's somehow better than `CACurrentMediaTime`.
What's more, I made `_wantRunUpdates` usable again.
Made some refactor.
When value gets detached from all component it can be still kept in memory and attached to some other component at later time. But because we don't know when JS reference is dropped we need to delete native counterpart of the value when it gets detached. This has led to a situation in which the value was reinstantiated on the native site. In that case if the value has changed we expect it to persist that changes when it gets attached again. This wasn't happening and each time the value was instantiated we'd always use the initial value.
With this change we are solving that issue by querying the value right before we detach the native node and then we use that value to update config such that next time when it gets instantiated it uses updated value instead of the initial one.
On iOS the behavior of running node updates was unpredictable for the case when new view has been attached. In such a case if it was required to run some updates (e.g. view has a transform that links to another nodes that require updates) we may ended up only running these in the next frame. The reason was that we'd use CADisplayLink to schedule animation callback but since we already run on UI thread the callback would only run in the next frame. As a result the view would first render with default params (e.g. no transform), then on the next frame the transform would update to the initial values. This was causing the view to flash with unexpected props applied for a single frame and only then be placed as expected.
In this change we force trigger onAnimationFrame callback if we suspect module operations (e.g. connect node to view) have requested updates. It does not matter if they didn't, as worse case we would run update loop twice. In that case the queues should be empty and when we run it for the second time there should be no additional computation being made.
This fix is not necessary on Android where we use ReactChoreographer. The reason is that choreographer has several buckets of callbacks that can be enqueued. We use `CallbackType.NATIVE_ANIMATED_MODULE` bucket which always runs after `DISPATCH_UI` which is used to run all module operations. So if operation requests an update the animation callback will run in the same frame in which it's been requested.
After start/stop API landed we started evaluating graph of nodes in topological order. In order for that to work we needed to create a stack of final node to be evaluated and run it in particular order. What might happen during evaluation is that some new nodes can be marked as updated (e.g. we use set node to update a value in a different nodes subtree). In such a case we want to update views that newly marked node may have impact on.
Here we also changed Android to use ArrayList instead of SparseArray for the list of updated nodes. This is to make it consistent with iOS implementation where we use a regular list too. In practice it won't happen too often that a view is added to a queue several times. Even if that happens, we still will evaluate the node at most once per frame.
This PR adds new "round" and "color" nodes.
Color nodes can be used to map to color props in view (e.g. backgroundColor)
Round is required for the color math to function properly (each color component needs to be an integer).
Added demo app where you can pan view around that changes color depending on the position on HSV palette.
