WinUI Navigation Handler

[PureWeen]

Description of Change

Most of the file changes have to do with namespace changes because of types moved into controls from compatibility and then renaming WINDOWS to WINDOWS

The good bits are all inside the Controls.Core and the Core project
That's the main code to focus on

Changes

Moving files from Compatibility to Controls.Core

• if the type/interface (ITitleProvider) is internal then I just copied the file over which means there are two copies
• If the type/interface is public then I moved it from Compatibility to Controls.Core
• If the Extension class is public then for the most part I moved it to Controls.Core
  • A couple cases ColorExtensions.ToFormsColor and AccessibilityExtensions I split the file up where the extension method would no longer make sense in Controls.Core
• Public class types (VisualElementChangedEventArgs) I moved to Controls.Core so Compat/Core worked off the same type
• Xaml ControlTemplates - I copy/pasted these over and renamed them from "Forms" to "Maui".
• I updated the CommandBar template to match the current WinUI template. The template we have now was generated from 12041 6 years ago. We'll want to validate against some UI tests once we are up and running in the CG (Allow CommandBar to expand and show command labels xamarin/Xamarin.Forms#594)
• Moved the Platform.UpdateToolBarItems into ToolbarManager.UpdateToolBarItems (This will need to be updated to handle multiple windows)

Observations

• every place we use async void should be verified when moved over
  • does it try catch? (use fireandforget)
  • does it validate that the handler is still in a state that the results are valid?
  • Is there a way to make this all more mapper friendly so we don't need async/void? Once we get the new image stuff a lot of the async/void should be able to go away
• I tried to use IView instead of VisualElement wherever I could but we will probably try to have a later effort to really take this one home
• I'll add Issues for all the "//TODO MAUI" stuff
• There are some APIs that will only work on UWP which I have left around on the assumption that some day we're going to have a UWP WinUI target so I don't want to delete that code

Additions made

• I added a Task.FireAndForget into Core that try/catches for async/void
• Added UseMauiControlsHandlers builder extension which will register all the maui controls handlers and whatever other types are needed
• I put all of the platform specific bits under the "MS.Maui.Controls.Platform" Namespace
• I collapsed all of the Windows Windows_UWP if defs just into "WINDOWS" and I removed any UWP specific code because this code isn't relevant anymore. I realize earlier on I said I left some UWP code but that was only for scenarios where the API is available to UWP. The area's I removed should have APIs that match WinUI desktop if/once uwp comes around

Removals made

• Bits that I moved over to Controls that work marked as hidden from intellisense I marked as internal. Because we are just going to be compiling the handlers along side the Controls.Core in the same assembly they don't have to cross the assembly line anymore

Testing

WinUI still doesn't draw without a window resize so you have to resize the window, then you can click the navigate button, then resize the window again to see the new page

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 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?

• 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.

[PureWeen]

AFAICT this code never executed even on old forms

[mattleibow]

Wow... Big one. Most look OK, and I am going to trust that because a bunch of the code is copied form the renderer that this is safe to use. I got a few questions more along the line of "what is this doing as I don't understand?"

[mattleibow]

The usage of the extension methods as normal methods is a little sus :) But no biggie.

Let's merge this one and then we can get nav working