Adds Rendering driver option to NativeAnimated (#9249)

* Adds Rendering driver option to NativeAnimated

Currently, NativeAnimated compiles the animation graph into
CompositionAnimations from UI.Composition. While this approach likely
provides the ideal performance for native animations on Windows, it
suffers a few insurmountable limitations:

1. #8419: Creating a new animation on an animated value after stopping a
previous animation on the same value does not retain the current value.
  a. Even with a fix like #9190, because UI.Composition values cannot be
  queried synchronously, starting a new animation on an animated value
  immediately after stopping a previous animation causes jitter in the
  animation, because it takes 1-2 frames for the completion callback to
  fire, signaling that the animated value has an up-to-date value.
2. #3283: UI.Composition can only animate supported properties, like
opacity and transforms. NativeAnimated provides a prop "hook" (the prop
name is `progress`) to allow arbitrary views to subscribe to animation
value changes synchronously. This is not possible with UI.Composition.
3. #4311: Similar to the limitation for starting new animations
synchronously after stopping a previous animation on the same animated
value (#8419), animated value listeners will always be 1-2 frames out of sync
while waiting for an up-to-date composition value. This feature is
currently not implemented for the UI.Composition approach, but I suspect
it would require a frame callback via CompositionTarget::Rendering, so
not only would the values be out of sync, but the approach would have a
similar performance profile to the CompositionTarget::Rendering driven
animations.
4. #9255: Similar to #3283, it's actually possible to animate arbitrary
props with Animated (e.g., `borderRadius`). It's unlikely that it would
be possible to support such an animation with UI.Composition.

There are also a few bugs that are likely possible to workaround for
UI.Composition, but would be fixed immediately by this
CompositionTarget::Rendering approach:
1. #3460: Animated values persist even after the animation is unmounted
with UI.Composition. The CompositionTarget::Rendering approach uses the
view's shadow node as the source of truth for the prop value, and resets
the prop to null when the animation is unmounted.
2. #9256: The UI.Composition implementation for NativeAnimated
commandeers the `Offset` value for animated nodes, using it to drive
progress on an animation. Animated value offsets are not intended for this
purpose and can cause bugs as demonstrated in the linked issue.
3. #9251: Calling `setValue` on an animated value should stop any active
animations and update the animation graph to reflect the value that was
set, but in the UI.Composition implementation, the animation is only
stopped in place.
4. #9252: Animated.diffClamp nodes are intended to clamp the difference
between the last value and the current value, but the UI.Composition
`clamp` expression only has the capability to clamp the current value.
5. #9250: Calling `getValue` on an animated value does not return the
current value for the UI.Composition approach (because values are not
available until the animation has been stopped and the completion
callback fires).
6. A more minor issue that I haven't filed an issue for, is that
Animated.decay animations work slightly differently in NativeAnimated
vs. JS-driven animations. The NativeAnimated approach is a bit more
"accurate", in that it stops the animation when its value is within 0.1
of the final value if the decay ran infinitely. The JS-driven approach
stops the animation more eagerly when the value differential (the
difference between the current value and the previous value) is 0.1.

This change allows each animation node and driver to be used in either
composition mode or frame callback / CompositionTarget::Rendering mode.
The latter approach is largely derived from the Android implementation
of NativeAnimated (and the C# implementation in react-native-windows
v0.59 and earlier).

This change will leverage WIP changes to the Animated APIs in RN core
that pass a property bag to each AnimationDriver and AnimatedNode
signaling which mode to use. The API surface will look something like
the following:

```js
const value = Animated.value(0);

Animated.timing(value, {
  ...,
  useNativeDriver: true,
  platformConfig: {
    useComposition: false,
  });
```

We will also likely complement this API change with a way to set default
`platformConfig` values for all Animated APIs using `useNativeDriver:
true`:
```js
Animated.setDefaultPlatformConfig({useComposition: false});
```

For now, in order to not regress performance on existing
react-native-windows applications, using the
CompositionTarget::Rendering approach will be strictly opt-in. As of
this commit, these two approaches cannot be blended together. I.e., you
cannot connect a node using UI.Composition to a node using
CompositionTarget::Rendering, and it's unlikely these two approaches
could be combined until the UI.Composition approach supports synchronous
queries of values (at which point, quite a few of the justifications for the
CompositionTarget::Rendering approach will be resolved).

Fixes #3283
Fixes #3460
Fixes #8419
Fixes #9250
Fixes #9251
Fixes #9252
Fixes #9255
Fixes #9256

* Change files

* Adds RNTester example demonstrating bugs in UI Composition Animated

change/react-native-windows-bf20335c-eccd-487b-bbcf-9fcc46a3b849.json

@@ -0,0 +1,7 @@
+{
+  "type": "prerelease",
+  "comment": "Adds Rendering driver option to NativeAnimated",
+  "packageName": "react-native-windows",
+  "email": "erozell@outlook.com",
+  "dependentChangeType": "patch"
+}