[Mono.Android] Provide enum overload of PackageManager.PackageInfoFlags.Of.

[jpobst]

Fixes #7729

We do not currently enumify PackageManager.PackageInfoFlags.Of (long) (source) because it is a long and our tooling is built around enumifying int values.

However, it seems to be a relatively used API so we should try to make it nicer.

Create a new PackageInfoFlagsLong long enum that can be used as a parameter to a new Of overload.

[jonpryor]

Should this instead be named PackageInfoFlagsLong, as IntelliSense code completion for tokens starting with PackageInfoFlags would then show PackageInfoFlagsLong as possible completions?

[jpobst]

If you've already typed out PackageInfoFlags then you aren't really using Intellisense! 😁

Generally you don't have to type any part of an enum type name because Intellisense is already showing it to you because it knows the parameter type.

Regardless, either seems fine, changed.

[jonpryor]

Why are Of() and ValueAsFlags are marked as unsafe?

[jpobst]

Copy/paste error, removed.

[jonpryor]

Two thoughts/questions:

1. Instead of hardcoding the values ("from documentation"), could this instead re-use our existing enum for existing non-long values?

   public enum PackageInfoFlagsLong : long {
       GetActivities = PackageInfoFlags.Activitites,
       GetServices = PackageInfoFlags.Services,
       // …
   }

2. Why the "naming change" between PackageInfoFlags and PackageInfoLongFlags? PackageInfoFlags.Activities is PackageInfoLongFlags.GetActivities, etc. On the one hand this "new" convention may be "better", but it also means that migrating from the old enum to the new enum will require additional edits; you can't "just" change the enum name.

[jpobst]

1. Good thought, updated.
2. This seemed like a good opportunity to fix a "mistake" from the past.

I don't know that changing GetDisabledComponents to DisabledComponents was ever a good idea, but now that MatchDisabledComponents (and others) have been added, it seems too confusing to have one of them missing the verb.

[jpobst]

Also added [ObsoletedOSPlatformAttribute]'s as specified in Android docs.

[jonpryor]

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

We do not currently enumify
[`PackageManager.PackageInfoFlags.of(long)`][0] because it is a
`long` and our tooling is built around enumifying `int` values.

However, it seems to be a frequently used API, so we should try to
make it nicer.

Create a new `PackageInfoFlagsLong` enum which has `long` as the
underlying type, which can be used as a parameter to a new
`PackageManager.PackageInfoFlags.Of(PackageInfoFlagsLong)` overload:

	var flags = PackageManager.PackageInfoFlags.Of(
	    PackageInfoFlagsLong.GetActivities |
	    PackageInfoFlagsLong.GetSignatures
	);
	// vs previous
	var old_flags = PackageManager.PackageInfoFlags.Of(
	    (long)(PackageInfoFlags.Activities | PackageInfoFlags.Signatures)
	);

Note that the enumeration member naming convention changed, e.g.
from `PackageInfoFlags.Activities` to
`PackageInfoFlagsLong.GetActivities`.  This was done because the
verbs used by `PackageInfoFlags` members were not consistent; some
members had an "implicit `Get`" e.g. `PackageInfoFlags.Activities`
(which came from `PackageManager.GET_ACTIVITIES`), while others had
an "explicit" verb, e.g. `PackageInfoFlags.MatchUninstalledPackages`
(which came from `PackageManager.MATCH_UNINSTALLED_PACKAGES`).
The new `PackageInfoFlagsLong` convention is to consistently require
the verb.

[0]: https://developer.android.com/reference/android/content/pm/PackageManager.PackageInfoFlags#of(long)