[workload] setup C# implicit global usings from MSBuild

[jonathanpeppers]

Description of Change

Context: #3018
Context: xamarin/xamarin-macios#13196
Context: dotnet/android#6447

PR #3018 was a good start in enabling implicit C# global usings.
However, there were a couple of issues to work through:

1. There is a GlobalUsings.cs file. Can we do this in MSBuild, so
   it's just there by default? I added:

<ItemGroup Condition=" '$(UseMaui)' == 'true' and ('$(ImplicitUsings)' == 'true' or '$(ImplicitUsings)' == 'enable') ">
  <!-- %(Sdk) is only here if something later needs to identify these -->
  <Using Include="Microsoft.Extensions.DependencyInjection" Sdk="Maui" />
  <Using Include="Microsoft.Maui" Sdk="Maui" />
  <Using Include="Microsoft.Maui.Controls" Sdk="Maui" />
  <Using Include="Microsoft.Maui.Controls.Hosting" Sdk="Maui" />
  <Using Include="Microsoft.Maui.Controls.Xaml" Sdk="Maui" />
  <Using Include="Microsoft.Maui.Graphics" Sdk="Maui" />
  <Using Include="Microsoft.Maui.Essentials" Sdk="Maui" />
  <Using Include="Microsoft.Maui.Hosting" Sdk="Maui" />
</ItemGroup>

2. The platform-specific usings were not cleared. So types like
   Microsoft.Maui.Controls.Application could conflict with
   Android.App.Application.

To solve this, I added a %(Platform) metadata in the Android, iOS,
macOS, MacCatalyst, and tvOS workloads:

<Using Include="Android.App" Platform="Android" />
<Using Include="Android.Widget" Platform="Android" />
<Using Include="Android.OS.Bundle" Alias="Bundle" Platform="Android" />

Then in .NET MAUI's MSBuild targets we can do:

<ItemGroup Condition=" '$(UseMaui)' == 'true' and '$(MauiEnablePlatformUsings)' != 'true' and ('$(ImplicitUsings)' == 'true' or '$(ImplicitUsings)' == 'enable') ">
  <Using Remove="@(Using->HasMetadata('Platform'))" />
</ItemGroup>

I created $(MauiEnablePlatformUsings), just in case someone ever
needs to turn this off.

I updated the templates to specify ImplicitUsings=enable.

I updated Controls.Sample.Tests.csproj, as it was a .NET 6 project.
We probably can't update the other samples yet, because there are
Xamarin projects that would not support C# 10 language features.

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?

Nope

[Eilon]

I think this change is reasonable as-is and clearly solved a problem that we have right now that otherwise prevents using implicit using's.

Has there been any discussion with the relevant SDK/C# teams about this broad problem of SDK clashes with implicit using's and that we might eventually want to solve this more broadly? There are countless problems that occur when you have more than one SDK (e.g. Android+iOS, or iOS+Razor) and each one "knows best," except in cases like this where they know what's best very differently from each other 😁

[jonathanpeppers]

Has there been any discussion with the relevant SDK/C# teams about this broad problem of SDK clashes with implicit using's and that we might eventually want to solve this more broadly?

Last I heard there might be upcoming design for .NET 7. And the thought is right now NuGet packages shouldn't add implicit usings. (but someone probably will!)

It looks like I have a merge conflict here to fix, too...

[Eilon]

@jonathanpeppers sounds great!