Consider changing the names of the native app base types (MauiWinUIApplication, MauiApplication, MauiUIApplicationDelegate)

[Eilon]

These are the types in question for each platform:

• Windows (WinUI): MauiWinUIApplication
• Android: MauiApplication
• iOS/MacCatalyst: MauiUIApplicationDelegate

Why change the names?

• The names are not consistent with each other.
• These type names are not usually seen by developers, so using up "good" names such as MauiApplication might be a "waste". These types are typically used once per project in a file generated by the project template (i.e. the user doesn't type it in)
• This would mean "good" names such as MauiApplication could be used in more user-facing APIs that are more frequently worked on by developers, such as in the app's startup code (which, in my experience, changes quite a lot over time)

Why not change the names?

• The name are consistent with the native base class names, which can be a benefit for someone familiar with the native architecture.
  • This doesn't preclude doing a rename, but perhaps the rename would be an "uglier" name that bears a resemblance to the native base class.
• The names are consistent with Xamarin.Forms (somewhat)

Note: This originally came up in this PR (and subsequent discussion in the PR).

[jsuarezruiz]

Already done in #2137

[Eilon]

Not really done. This issue is a follow-up from that PR where we wanted to consider any further unification or non-unification.

[rmarinho]

We should figure this out before going GA . Should we schedule a call ?

[Eilon]

@rmarinho yeah we could certainly do a call. I wonder does anyone have any proposals to share here, or any other thoughts on the pros/cons, or the "weights" of the pros/cons?

From my perspective, one of the biggest "weights" is to avoid "using up" a really good name such as MauiApplication for something that is almost never seen or interacted with directly by type name.

[Redth]

Considering the weight of this change to existing projects, we decided to leave it for NET6.

In .NET 7 we'll aim to do more source generation of these boilerplate implementations so these aren't as user facing. We can also consider obsoleting these in favour of a new name then (and making the obsolete ones subclass the new ones, and then remove them in net8).