[class-parse] support Module AttributeInfo

[jonpryor]

Fixes: #1096

Context: https://stackoverflow.com/questions/57358750/module-info-class-file-is-different-in-the-module-jar-file-and-compiled-module-i
Context: 678c4bd

JDK 9 adds support for modules, which are (kinda sorta) like
.NET Assemblies: modules can depend upon other modules, export
packages, etc.

In particular:

exports and exports…to. An exports module directive specifies
one of the module’s packages whose public types (and their nested
public and protected types) should be accessible to code in all
other modules.

This allows an equivalent to the C# internal access modifier:
public types in a non-exported package should be treated as
"internal", while public types in an exported package are
"fully public".

Update Xamarin.Android.Tools.Bytecode.dll to extract the module-
related information, the update XmlClassDeclarationBuilder so that
it updates all public types outside of the "exported" packages to
have a visibility of kotlin-internal.

Why a //*/@visibility value of kotlin-internal? From a
suggestion for the commit message of 678c4bd, which was sadly
overlooked in the final merge:

Note: we introduce and use a new //*/@visibility value of
kotlin-internal because internal is an existing value that may
be used in Metadata.xml files, e.g. making public API internal
so that it can still be used in the binding, but isn't public.

If we use internal, those types are still bound, it's just that
the bound types have C# internal visibility, while we want them
to be skipped entirely. A visibility value of kotlin-internal
allows us to skip them, which is desired.

tests/Xamarin.Android.Tools.Bytecode-Tests has been updated to:

1. Contain a module-info.java, which declares a com.xamarin
   module.

2. Add a new com.xamarin.internal.PublicClassNotInModuleExports
   type which is not in the com.xamarin package, but instead
   a nested package. The type is public.

3. Build a xatb.jar artifact

This makes for a simple one-off test:

% dotnet build tests/Xamarin.Android.Tools.Bytecode-Tests/*.csproj
% dotnet build tools/class-parse/*.csproj
% dotnet bin/Debug-net7.0/class-parse.dll \
  tests/Xamarin.Android.Tools.Bytecode-Tests/obj/Debug-net7.0/xatb.jar
…
    <class
      name="PublicClassNotInModuleExports"
      …
      visibility="kotlin-internal" />

Note that com.xamarin.internal.PublicClassNotInModuleExports is now
shown as kotlin-internal instead of public.

Aside, a discovered oddity: jar cf … modifies module-info.class,
adding a ModulePackages attribute! (Specifically, if you compare
the "on-disk" module-info.class to the one within
tests/Xamarin.Android.Tools.Bytecode-Tests/obj/$(Configuration)/xatb.jar,
they differ in size!)

[jonpryor]

/azp run

[azure-pipelines]

No pipelines are associated with this pull request.

[jpobst]

Is this going to undo #1093?

That is, will this write module-info.class into api.xml?

[jonpryor]

Yes, it will "undo" #1093, and No, it will not write module-info.class into api.xml. (I should explicitly call this out in the commit message; doh!)

See FixupModuleVisibility(), in particular https://github.com/xamarin/java.interop/pull/1097/files#diff-cd606380b5886cb27bfcf4f255f042d4cb739a6a33545920a305cba1113dac74R386

We do two things in FixupModuleVisibility():

1. We collect all of the ClassFile entries of type ClassAccessFlags.Module, and remove them from classFiles. This prevents them from being written into api.xml.
2. For the ClassFile entries in (1), we find the set of exported packages (in publicPackages), and (2) iterate over every entry in classFiles. Any classFiles entry with a package name outside of publicPackages has its visibility updated to ClassAccessFlags.Internal.

One problem with this approach, not considered until just now, is that if class-parse is parsing multiple .jar files and writing out a single api.xml, then the module-info.class information would be applied to entries from a different .jar. This may result in "weird" behavior, and I'll need to think about this.

[jpobst]

It occurs to us that properly supporting Modules may potentially remove API's that AndroidX/GPS (and external bindings) have already shipped as "public".

[jonpryor]

@jpobst: latest commit attempts to resolve the two open issues:

Regarding:

It occurs to us that properly supporting Modules may potentially remove API's that AndroidX/GPS (and external bindings) have already shipped as "public".

We now keep visibility as public, and use the annotated-visibility XML attribute added as part of @RestrictTo processing to store module-info if a type should be hidden. This should maintain API compatibility in AndroidX/etc.

To address my concern about .jar "pollution":

if class-parse is parsing multiple .jar files and writing out a single api.xml, then the module-info.class information would be applied to entries from a different .jar.

This is addressed by altering class-parse command-line handling. If a .jar or .jmod file is encountered, then module-info.class-based visibility fixups are done local to that .jar file. The module-info.class files from one .jar won't be used to process other .jar files.