[One .NET] version .NET 6 packages with Android API level (#5924)

Our current versions for .NET 6 packages use the Android OS Version
version number, with `XXX` is the git "commit distance":

	11.0.200-preview.4.XXX

e.g. (via c1fafcb1):

	Microsoft.Android.Runtime.android-arm64.11.0.200-preview.4.251.nupkg

This is the only place where Android "11" remains, as we have been
using the Android API level for all other versions in .NET 6, e.g.
commit 91498d5.

We should instead use an API-level, such as:

	30.0.100-preview.4.XXX

as in:

	Microsoft.Android.Runtime.android-arm64.30.0.100-ci.pr.gh5924.1.nupkg

We believe that this will make things less confusing, as this matches
the Android Target Framework Moniker as well:

	net6.0-android30

Author: jonathanpeppers

Directory.Build.props

@@ -16,11 +16,12 @@
     <ProductVersion>11.3.99</ProductVersion>
     <!-- NuGet package version numbers. See Documentation/guides/OneDotNet.md.
          Rules:
+         * Major/Minor match Android stable API level, such as 30.0 for API 30.
          * Reset patch version (third number) to 100 every time either major or minor version is bumped.
          * Bump last two digits of the patch version for service releases.
          * Bump first digit of the patch version for feature releases (and reset the first two digits to 0)
     -->
-    <AndroidPackVersion>11.0.200</AndroidPackVersion>
+    <AndroidPackVersion>30.0.100</AndroidPackVersion>
   </PropertyGroup>
 
   <!-- Common <PackageReference/> versions -->

Documentation/guides/OneDotNet.md

@@ -293,8 +293,8 @@ see the [net6-samples][net6-samples] repo.
 
 This is the package version scheme: `OS-Major.OS-Minor.InternalRelease[-prereleaseX]+sha.1b2c3d4`.
 
-* Major: The major OS version.
-* Minor: The minor OS version.
+* Major: The highest stable API level, such as 30. On Apple platforms, this is the major OS version.
+* Minor: Always 0 for Android. On Apple platforms, this is the minor OS version.
 * Patch: Our internal release version based on `100` as a starting point.
     * Service releases will bump the last two digits of the patch version
     * Feature releases will round the patch version up to the nearest 100
@@ -305,16 +305,16 @@ This is the package version scheme: `OS-Major.OS-Minor.InternalRelease[-prerelea
     * For CI we use a `ci` prefix + the branch name (cleaned up to only be
       alphanumeric) + the commit distance (number of commits since any of the
       major.minor.patch versions changed).
-        * Example: `10.0.100-ci.master.1234`
+        * Example: `30.0.100-ci.master.1234`
         * Alphanumeric means `a-zA-Z0-9-`: any character not in this range
           will be replaced with a `-`.
     * Pull requests have `pr` prefix, followed by `gh`+ PR number + commit
       distance.
-        * Example: `10.1.200-ci.pr.gh3333.1234`
+        * Example: `30.0.200-ci.pr.gh3333.1234`
     * If we have a particular feature we want people to subscribe to (such as
       an Android preview release), we publish previews with a custom pre-release
       identifier:
-        * Example: `10.1.100-android-r.beta.1`
+        * Example: `30.0.100-android-r.beta.1`
         * This way people can sign up for only official previews, by
           referencing `*-android-r.beta.*`
         * It's still possible to sign up for all `android-r` builds, by
@@ -324,15 +324,15 @@ This is the package version scheme: `OS-Major.OS-Minor.InternalRelease[-prerelea
         * Use the short hash because the long hash is quite long and
           cumbersome. This leaves the complete version open for duplication,
           but this is extremely unlikely.
-    * Example: `10.0.100+sha.1a2b3c`
-    * Example (CI build): `10.0.100-ci.master.1234+sha.1a2b3c`
+    * Example: `30.0.100+sha.1a2b3c`
+    * Example (CI build): `30.0.100-ci.master.1234+sha.1a2b3c`
     * Since the build metadata is required for all builds, we're able to
       recognize incomplete version numbers and determine if a particular
       version string refers to a stable version or not.
-        * Example: `10.0.100`: incomplete version
-        * Example: `10.0.100+sha.1a2b3c`: stable
-        * Example: `10.0.100-ci.d17-0.1234+sha.1a2b3c`: CI build
-        * Example: `10.0.100-android-r.beta.1+sha.1a2b3c`: official
+        * Example: `30.0.100`: incomplete version
+        * Example: `30.0.100+sha.1a2b3c`: stable
+        * Example: `30.0.100-ci.d17-0.1234+sha.1a2b3c`: CI build
+        * Example: `30.0.100-android-r.beta.1+sha.1a2b3c`: official
           preview
             * Technically it's possible to remove the prerelease part, but
               we’d still be able to figure out it’s not a stable version by