Ensure that all native callbacks are setup always

[nirinchev]

This is another fun episode of "why does the Unity Editor hang". Here's a list of the high level changes:

1. Removed should_compact_callback from the native configuration and moved the static initialization to RealmHandle.Initialize. We were always passing a pointer to the same managed method, so figured it makes sense to only initialize once.
2. RealmConfiguration.CreateRealm now disposes the Migration instance and the GCHandle referencing the ShouldCompactDelegate in a finally block after creating a Realm instance. This is an alternative fix for the leak reported in Fix memory leak. #1788.
3. Encapsulated the awkwardness around getting a native schema inside SharedRealmHandle/ObjectHandle. Previously those exposed an API where you needed to pass an Action<Schema> and now everything is handled internally and they just return the Schema that would have otherwise been passed to the callback.
4. NativeCommon.Initialize now invokes all handle initializers to install the managed callbacks. This is done to avoid bugs where the user creates an App, logs a user in, but doesn't open a Realm instance from managed code. This would then result in a bug where the native sync manager would open the metadata Realm to store the user's information but would then fail to do that because the synchronization context hooks haven't been setup, so it'll be calling into the void trying to check if there's a synchronization context on the background thread.
5. Related to ^ AppHandle's and SharedRealmHandle's static constructors will call NativeCommon.Initialize which should ensure there's no way to call into native without first initializing the callbacks.
6. Moved ApiKeysCallback from SyncUserHandle to AppHandle to streamline the callback setup (it was the only callback setup by the SyncUserHandle).
7. Reworked the awkward way of calling native async API. Previously, the handle API would expect a TaskCompletionSource<T> argument, would create a GCHandle for it and then rely on the callback to free it. This was both annoying to consume and error prone (there was one case where we forgot to free a handle correctly). Instead, now all async APIs will encapsulate the tcs creation, invoking the native API, awaiting the tcs.Task and then freeing the GCHandle in a finally block (these are most of the changes in AppHandle and SyncUserHandle).
8. Picks up Close the SyncManager on app destruction realm-core#4616 which ensures that destroying an app will close its sync manager and associated sessions. To make sure that apps are actually freed, we call App::clear_cached_apps when unloading the AppDomain.

In terms of the actual reason for the hangs, they were a couple:

1. We weren't correctly initializing the synchronization context hooks before a Realm is opened, so native Realm instances created by the App were causing either crashes or hangs when trying to check the synchronization context. (4 above)
2. We wouldn't clean up cached apps between domain reloads so we would get stale apps that reference managed state that is no longer valid (e.g. the logger) and all sorts of weird behavior for the sync client. (8 above)

[papafe]

Looks ok to me, at least for the parts I can understand :)

[LaPeste]

Thank you for the long intro in the PR, it's helped getting a bit of context. I tried to follow all the points you wrote and they seem to be reflected in code.
I'm rather confident that this PR is going to be a good candidate for the next PR review, at the very list to tell some of the background behind the discovery of the reasons for the hangs in Unity.

[nirinchev]

Needs realm/realm-core#4635 before it's merged.