Fixes: dotnet#3690
Fixes: dotnet#6626

Changing `$(ApplicationDisplayVersion)` inside Visual Studio causes
builds to fail:

    Error NU1105 Unable to read project information for 'MauiApp15': Sequence contains more than one element
    Error NU1105 Unable to read project information for 'MauiApp15': Sequence contains more than one element
    Error NU1105 Unable to read project information for 'MauiApp15': Sequence contains more than one element
    Error NU1105 Unable to read project information for 'MauiApp15': Sequence contains more than one element

You get this error once per `TargetFramework`. Builds outside VS work
fine! `dotnet build` succeeds.

I was able to attach a debugger to VS, and hit a breakpoint on this
line in NuGet:

https://github.com/NuGet/NuGet.Client/blob/82630f7f8fb5114a207c295f2f9bea1bc2a6b3cf/src/NuGet.Clients/NuGet.SolutionRestoreManager/VsSolutionRestoreService.cs#L227

With a stack trace of:

    This exception was originally thrown at this call stack:
    System.Linq.Enumerable.SingleOrDefault<TSource>(System.Collections.Generic.IEnumerable<TSource>)
    NuGet.SolutionRestoreManager.VSNominationUtilities.GetPackageVersion(System.Collections.IEnumerable) in VSNominationUtilities.cs
    NuGet.SolutionRestoreManager.VsSolutionRestoreService.ToPackageSpec(NuGet.VisualStudio.ProjectNames, System.Collections.IEnumerable, string, string) in VsSolutionRestoreService.cs
    NuGet.SolutionRestoreManager.VsSolutionRestoreService.ToDependencyGraphSpec(NuGet.VisualStudio.ProjectNames, NuGet.SolutionRestoreManager.IVsProjectRestoreInfo, NuGet.SolutionRestoreManager.IVsProjectRestoreInfo2) in VsSolutionRestoreService.cs
    NuGet.SolutionRestoreManager.VsSolutionRestoreService.NominateProjectAsync(string, NuGet.SolutionRestoreManager.IVsProjectRestoreInfo, NuGet.SolutionRestoreManager.IVsProjectRestoreInfo2, System.Threading.CancellationToken) in VsSolutionRestoreService.cs

This appears to be caused by an issue with NuGet inside Visual Studio:

NuGet/Home#6461

If you get a different `$(PackageVersion)` for any TF, you run into
this.

It appears we set `$(Version)` based off of
`$(ApplicationDisplayVersion)` in all of the mobile workloads:
Android, MacCatalyst, iOS, etc. Then `$(PackageVersion)` is also based
on `$(Version)`.

* https://github.com/xamarin/xamarin-android/blob/d4da1c252f45c4910abc1bd9e5be9ecf9dc683a0/src/Xamarin.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.DefaultProperties.targets#L114
* https://github.com/xamarin/xamarin-macios/blob/b84b80902c91cc99e88aac734761c9d0d99ce42f/dotnet/targets/Xamarin.Shared.Sdk.targets#L7

Except when using MAUI for net6.0-windows. To workaround this issue,
we can put the same code in `WinUI.targets`:

    <Version Condition=" '$(ApplicationDisplayVersion)' != '' ">$(ApplicationDisplayVersion)</Version>

This seems reasonable for our WinUI support in MAUI anyway, as we have
code that makes `$(ApplicationDisplayVersion)` work there.