[workload] create $(MauiVersion) property

[jonathanpeppers]

Description of Change

Context: https://github.com/jonathanpeppers/maui-workload-pinning

We currently have a $(MicrosoftMauiSdkVersion) property you can
change that allows you to grab newer targeting and runtime packs for
.NET MAUI. Unfortunately, there is not a way to do this for MAUI's
MSBuild tasks for things like XamlG, XamlC, Resizetizer, etc.

Some improvements here:

1. Rename $(MicrosoftMauiSdkVersion) to $(MauiVersion). If this is
   going to be a thing people use, let's choose a shorter name.

2. Move Microsoft.Maui.Resizetizer.Sdk into a library-pack. Bring
   it in via an implicit @(PackageReference).

3. Split up parts of Microsoft.Maui.Controls.Sdk into a new
   library-pack named Microsoft.Maui.Controls.Build.Tasks. Bring
   it in via an implicit @(PackageReference).

Now users will be able to have some minimum version of the .NET MAUI
workload installed. They can independently change $(MauiVersion) in
different projects to use different versions of .NET MAUI.

This behavior may be temporary, so I left some code in place if we
want to revert this behavior and turn these new library-packs into
regular workload packs. At some point, workload installation may be
the preferred (and only way) for installing .NET MAUI.

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

[jonathanpeppers]

If you build dotnet/installer locally, it has this version number.

I thought we could put the same here, so this check would pass:

maui/.nuspec/Microsoft.Maui.Controls.targets

Lines 45 to 47 in 887e65e

	<Error Code="MAUI004"
	Text="At least version '$(_MinimumMauiWorkloadVersion)' of the .NET MAUI workload is required to use &lt;MauiVersion&gt;$(MauiVersion)&lt;/MauiVersion&gt;."
	Condition="'$(MauiWorkloadVersion)' != '' and '$(MauiVersion)' != '' and $([MSBuild]::VersionLessThan($(MauiWorkloadVersion), $(_MinimumMauiWorkloadVersion)))" />

NOTE: [MSBuild]::VersionLessThan() ignores semver, so we'd need to tweak this if it ever matters.

[jonathanpeppers]

This file is not currently used in this PR anymore, but I left it here if we want to go back in the future? I think there is still some uncertainty here.

[jonathanpeppers]

This is the major change here -- these two packs are library-packs and an implicit @(PackageReference) is brought into Maui projects.

[Redth]

@jonathanpeppers can $(MauiVersion) be a floating version? is there a way this could be discoverable from NuGet package manager?

[jonathanpeppers]

I don't think there is a way for the NuGet package manager to show this... I guess we could make some package that you add to your project that could do it? Some Microsoft.Maui package could set MauiVersion in its MSBuild targets inside.

I asked about floating versions here: dotnet/docs#25813 (comment)

I could try and just see if it works.

[Redth]

Floating numbers could be a reasonable answer. I do like the idea of some other meta package that we publish too that just sets the version, that's a simple enough work around that would surface in the package manager updates UI.

[mattleibow]

Feels like all things are right, CI passed. Now for the real test by updating my local machine and pretend I am in the real world!

[mattleibow]

@jonathanpeppers I see this was removed so no $(UseMauiAssets) no longer applies. However, since this is now a dependency of the Microsoft.Maui.Controls.Sdk, we might also need to add the condition to the line above?

It doesn't seem to pull in anything else.

[jonathanpeppers]

Good catch, it should be:

  <Import
      Condition=" '$(UseMaui)' == 'true' or '$(UseMauiCore)' == 'true' or '$(UseMauiEssentials)' == 'true' or '$(UseMauiAssets)' == 'true' "
      Project="Sdk.targets" Sdk="Microsoft.Maui.Controls.Sdk"
  />

One confusing thing is the name of this SDK, it has the name "Controls", but it's imported even when you're not using Controls.

Should we rename this one to Microsoft.Maui.Sdk? I would probably do that in a future PR.

[mattleibow]

Yeah, we can do that in a new PR so we can merge this one now.

[mattleibow]

All looking really good!