Fixes #2252, #2364, [SDKONCALL-214], [SDKONCALL-241].
See also #2078 and #2079.

when a background thread was in the middle of writing to `UserDefaults`
through `DeviceCache`, and at the same time, the main thread wanted to
read from it.
This is normally fine, except that if there are any `NotificationCenter`
observations on the `UserDefaults` used, the background thread would
then post that notification and wait for the main thread, leading to a
deadlock. What #2078 did was to use a different method to make sure that
the observation was received in the calling thread.
Additionally, #2079 avoided that observation whenever we used a
different `UserDefaults`.

When the SDK changed to a custom `UserDefaults` (#2046), we made the
choice to only do this if there was no prior data.
However, if an app has prior RevenueCat data saved in
`UserDefaults.standard`, that instance is used.

This potential deadlock is possible for any app with prior data, that
also contains observations to `UserDefaults`, either manually through
`NotificationCenter`, or using something like `@AppStorage` with
`SwiftUI`.

`DeviceCache.cachedAppUserID` is a very commonly used method. This PR
changes it to an in-memory cache, initialized to the `UserDefaults`
value.
By doing that, most code paths that rely on this value won't risk
deadlocking with `UserDefaults` writes that jump threads.

I've filed SDK-3034 to fully migrate data from `UserDefaults.standard`
to avoid this problem altogether in the future.

[SDKONCALL-214]:
https://revenuecats.atlassian.net/browse/SDKONCALL-214?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
[SDKONCALL-238]:
https://revenuecats.atlassian.net/browse/SDKONCALL-238?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
[SDKONCALL-241]:
https://revenuecats.atlassian.net/browse/SDKONCALL-241?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ

… not blocked

We've had a few reports of deadlocks (#2412, #2375). This might have not detected them, but it would detect future issues, as well as busy operations running on the main thread.

… not blocked (#2463)

We've had a few reports of deadlocks (#2412, #2375). This might have not
detected them, but it would detect future issues, as well as busy
operations running on the main thread.

Example:
![Screenshot 2023-05-01 at 9 50 22
AM](https://user-images.githubusercontent.com/685609/235492076-b84195ca-67e7-4762-8c56-49b1758c8534.png)

… not blocked (#2463)

We've had a few reports of deadlocks (#2412, #2375). This might have not
detected them, but it would detect future issues, as well as busy
operations running on the main thread.

Example:
![Screenshot 2023-05-01 at 9 50 22
AM](https://user-images.githubusercontent.com/685609/235492076-b84195ca-67e7-4762-8c56-49b1758c8534.png)

This was introduced in #2463, as a way to verify the SDK didn't have any deadlocks (#2412, #2375).
However, it has caused more trouble than it's worth, because that loop keeps the main thread busy.

This solution proposed by @aboedo makes it only check every 3 seconds.
If there is a deadlock, it would still detect it. But after it's verified there is no deadlock, it won't check again until that interval has elapsed again.

This makes it so that on a test that takes 6 seconds to run, we only execute this code 2 times instead of... a lot.