Add more APIs to IDispatcher

[mattleibow]

Description of Change

Part of #1965
Fixes #3950

This PR copies the API of Windows as that is fairly nice, and adds 2 new APIs:

public interface IDispatcher
{
+	bool DispatchDelayed(TimeSpan delay, Action action);
+	IDispatcherTimer CreateTimer();
}

+public interface IDispatcherTimer
+{
+	TimeSpan Interval { get; set; }
+	bool IsRepeating { get; set; }
+	bool IsRunning { get; }
+	event EventHandler Tick;
+	void Start();
+	void Stop();
+}

We now have a few ways to do timer-y things in Maui:

• System Timer objects
  These timer objects are using whatever the BCL uses to implement it. This may/may not sync with UI updates and things.
• Animations
  This is the logic used by our animations API, and is directly tied to the screen refresh rate. This is using the CADisplayLink and similar on other platforms.
• Dispatcher CreateTimer
  This is the new API and is a timer based on the dispatcher availability and frequency.

In order to chose which one to use, there are some simple rules:

• If you want to trigger some event in some work with relative accuracy, use the system/BCL timers
• If you want to have something that directly syncs to the screen refresh rate, use the animation APIs
• If you want to queue something on the UI thread repeatedly, use the dispatcher timers

PR Checklist

• Targets the correct branch
• Tests are passing (or failures are unrelated)
• Targets a single property for a single control (or intertwined few properties)
• Adds the property to the appropriate interface
• Avoids any changes not essential to the handler property
• Adds the mapping to the PropertyMapper in the handler
• Adds the mapping method to the WinUI, Android, iOS, and Standard aspects of the handler
• Implements the actual property updates (usually in extension methods in the Platform section of Core)
• Tags ported renderer methods with [PortHandler]
• Adds an example of the property to the sample project (MainPage)
• Adds the property to the stub class
• Implements basic property tests in DeviceTests

Does this PR touch anything that might affect accessibility?

• Does this PR introduce a new control? (If yes, add an example using SemanticProperties to the SemanticsPage)
• APIs that modify focusability?
• APIs that modify any text property on a control?
• Does this PR modify view nesting or view arrangement in anyway?
• Is there the smallest possibility that your PR will change accessibility?
• I'm not sure, please help me

If any of the above checkboxes apply to your PR, then the PR will need to provide testing to demonstrate that accessibility still works.