[api-merge] Fix for correctly calculating method level 'deprecated-since' attribute.

[jpobst]

Context: #7558

Currently when api-merge loops through type members, its first check is to see if there is any existing member with the same name. If there isn't, it can short-circuit, add the new member, and move to the next one. If there is, we compare the existing API level member to the new API level one to see if it has been marked deprecated in this level, and if so we can add the deprecated-since attribute.

However, this initial existing member check was solely done on member name, not signature. If the member is a method, a later check finds the exact matching method with the same signature. We are performing the deprecated-since logic against the first method with a matching name rather than the method with the same signature. Thus we are producing incorrect results.

This commit moves UpdateDeprecatedSince to be called after we have the method with the matching signature.

The acceptable-breakages changes reflect additional [Obsolete] attributes that are now being converted to [ObsoletedOSPlatform ("android-XX.0")] attributes.

[jonpryor]

Draft commit message:

Fixes: https://github.com/xamarin/xamarin-android/issues/7558

Context: https://github.com/xamarin/monodroid/commit/16338f99568db892f37f6b5ddf927c139fcd4f50
Context: a073d99a838d15a2e4977fda63ecb1064a214d49
Context: 938c349725b677f1fa291a94f12546ef3d3c5a60

Currently when `api-merge` loops through type members, its first check
is to see if there is any existing member with the same name.  If there
isn't, it can short-circuit, add the new member, and move to the next
one.  If there is, we compare the existing API level member to the new
API level one to see if it has been marked deprecated in this level,
and if so we can add the `deprecated-since` attribute.

However, this initial existing member check was solely done on member
*name*, not signature.  😱

If the member is a method, a later check finds the exact matching
method with the same signature.  We were performing the
`deprecated-since` logic against the first method with a matching name
rather than the method with the same signature.

For example, [`PackageManager.getPackageInfo(String, int)`][0], which
was deprecated in *API-33*.  Yet our binding uses `[Obsolete]`, meaning
it has been deprecated since API-21 or before!

	namespace Android.Content.PM;
	partial class PackageManager {
	    [global::System.Obsolete (@"deprecated")]
	    [Register ("getPackageInfo", "(Ljava/lang/String;I)Landroid/content/pm/PackageInfo;", "GetGetPackageInfo_Ljava_lang_String_IHandler")]
	    public override unsafe Android.Content.PM.PackageInfo? GetPackageInfo (string packageName, [global::Android.Runtime.GeneratedEnum] Android.Content.PM.PackageInfoFlags flags) => …
	}

This was wrong; it should instead have used `[ObsoletedOSPlatform]`:

	namespace Android.Content.PM;
	partial class PackageManager {
	    [global::System.Runtime.Versioning.ObsoletedOSPlatform ("android33.0")]
	    [Register ("getPackageInfo", "(Ljava/lang/String;I)Landroid/content/pm/PackageInfo;", "GetGetPackageInfo_Ljava_lang_String_IHandler")]
	    public override unsafe Android.Content.PM.PackageInfo? GetPackageInfo (string packageName, [global::Android.Runtime.GeneratedEnum] Android.Content.PM.PackageInfoFlags flags) => …
	}


Move the `UpdateDeprecatedSince()` invocations to be called *after*
we have the method with the matching signature.

The `acceptable-breakages` changes reflect additional `[Obsolete]`
attributes that are now being converted to
`[ObsoletedOSPlatform ("android-XX.0")]` attributes.

[0]: https://developer.android.com/reference/android/content/pm/PackageManager#getPackageInfo(java.lang.String,%20int)

[jonpryor]

@jpobst: one thing that concerns me is that tests/api-compatibility/acceptable-breakages-vReference-net8.0.txt doesn't have an entry for PackageManager.GetPackageInfo(string, PackageInfoFlags), which was #7558.

Shouldn't PackageManager.GetPackageInfo() be in acceptable-breakages-vReference-net8.0.txt?

[jpobst]

I verified that the package CI is building does include the new attributes:

Looking at the reference assembly we use for api-compat, the methods are not marked as [Obsolete] at all. Thus, this is simply an attribute addition and it will not show up in api-compat:

Our reference assembly must not have been updated since these methods were marked as deprecated.