Consolidate our MSIX distribution back down to one package (#15031)

We ship a separate package to Windows 10, which contains a copy of XAML
embedded in it, because of a bug in activating classes from framework
packages while we're elevated.

We did this to avoid wasting disk space on Windows 11 installs (which is
critical given that we're preinstalled in the Windows image.)

The fix for this issue was released in a servicing update in April 2022.
Thanks to KB5011831, we no longer need this workaround!

And finally, this means that we no longer need to depend on a copy of
"pre-release" XAML. We only did that because it would copy all of its
assets into our package.

Introduced in #12560
Closes #14106
Closes (discussion) #14981
Reverts #14660

custom.props

@@ -2,18 +2,6 @@
 <Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
   <!-- This file is read by XES, which we use in our Release builds. -->
   <PropertyGroup Label="Version">
-    <!--
-      The Windows 11 build is going to have the same package name, so it *must* have a different version.
-      The easiest way for us to do this is to add 1 to the revision field.
-      In short, for a given Terminal build 1.11, we will emit two different versions (assume this is build
-      4 on day 23 of the year):
-        - 1.11.234.0 for Windows 10
-        - 1.11.235.0 for Windows 11
-      This presents a potential for conflicts if we want to ship two builds produced back to back on the
-      same day... which is terribly unlikely.
-    -->
-    <VersionBuildRevision Condition="'$(TerminalTargetWindowsVersion)'=='Win11' and '$(VersionBuildRevision)'!=''">$([MSBuild]::Add($(VersionBuildRevision), 1))</VersionBuildRevision>
-
     <XesUseOneStoreVersioning>true</XesUseOneStoreVersioning>
     <XesBaseYearForStoreVersion>2023</XesBaseYearForStoreVersion>
     <VersionMajor>1</VersionMajor>