shared value new arch

This isn't a regression - it's the design of a new shared values.

You can think of the shared value as a shared memory that can be accessed by
many threads simultaneously. It requires control by a mutex to prevent volatile
memory access and potential application crashes.

In the previous approach, we maintained an additional copy of each shared value.
This copy was used to read them from JS thread, while the original was intended
for use on the UI thread. Reading shared values from the JS thread could occur
without blocking any threads, but it forced us to create a copy on each shared
value update and degrading animation performance.

Shared values are primarily intended for use on the UI thread. Considering
typical animation operations, you have one write operation on the JS thread,
while the rest of reads and updates take place on the UI thread. Therefore,
creating a copy on each update was a waste performance.

So we came up with a new idea and eliminated the need to copy on every update.
Instead, we now create a copy on demand because the reading of shared values in
JS occurs much less frequently than updates on the UI Thread. To create a copy
of a shared value that lives on the UI Thread, we synchronize both threads. This
involves waiting until the Reanimated UI Runtime is free, setting up a mutex,
creating the copy, and then unblocking the UI thread. This is why the JS thread
may need to wait briefly for the UI Runtime to become available. As a result,
we were able to significantly improve animation performance.