Move IDispatcher logic out of IPlatformServices

[mattleibow]

Description of Change

This PR moves the dispatcher and "run on main thread" logic out of the Forms/Device/IPlatformServices space and into Core and Controls.

Core has the basic logic for executing on a "platform amin thread" and Controls attaches that logic to all BindableObjects.

Part of #1965

Discussion

Due to backwards compatibility, I have actually implemented this "wrong" in the objective sense. This is because we allow UI objects to be created and used off the UI thread.

For example, If I start up a background thread and on that background thread I create a Button. Firstly, that is incorrect because logic in the constructor is now running on a background thread. Second, when I use the Dispatcher property, what thread should I use? Right now I just thrash around and try things until I find one.

Now, the thing that sort of holds this together is that there typically is only 1 UI thread. In most cases. Even in Windows with multiple windows because the default way we create windows is on the same thread. So we are lucky. However, this is not fixed. The user or maui may opt to create windows in separate threads - especially if the windows do a lot of work.

We then may enter a world of pain. For example this execution:

1. Assume on UI thread 1
2. Create background thread B
3. Create a button myButton on B
4. App creates a second window on a new UI thread 2
5. App executes myButton.Dispatcher.Invoke from B (probably will pick UI 1)
6. App closes first window on thread 1
7. App executes myButton.Dispatcher.Invoke from B :
   1. App picks UI 1 because it is cached and will throw
   2. App picks UI 2 because we decide not to cache
8. We now have one UI element in a background thread that either crashed or executed on another thread and have lost consistency

Additions made

• Moved IDispatcher and IDispatcherProvider to Core.
• Added specific instances of dispatcher objects to the IMauiContext.
• Moved the very weirdly-specific logic out of the MauiContext ctors and into the correct scoping methods as they fit better there.
• Obsoleted the various methods on Device.
• Update the usage of Device.* to use the dispatchers.

[KPixel]

I wasn't aware that this was possible in Xamarin.Forms. If it isn't desired in MAUI, maybe we can keep it only in compatibility mode (opt-in). Or, if it is still necessary, I just hope that it doesn't "compromise" the normal way of building UI on their UI thread.

I am waiting for multi-window and CollectionView to be available on Windows (in Preview 11 hopefully). Then, I will port my app to MAUI and see if any of these potential issues still occur.

Edit: I'm glad to see Device.BeginInvokeOnMainThread() go away; it was the cause of many bugs. Application.Current.Dispatcher should also be avoided as much as possible for the same reason.