Add cswin32 mode to generate [GeneratedComInterface] and [LibraryImport] code

[jevansaks]

CsWin32 is built as a source generator, which has the limitation that its generated code cannot be seen by other source generators. This means types that cswin32 generates (e.g. HRESULT) can't be used in things like P/Invoke source generation and cswin32 itself can't generate code that uses attributes which trigger other source generators.

This is especially problematic for trying to use cswin32 in Native AOT because we cannot use runtime marshaling, and so all of the ComImport-generated code that cswin32 produces does not work. Thus far, anyone wanting to use cswin32 in NAOT has to set allowMarshaling:false and use cswin32 in blittable mode, which is not very friendly.

This change does 2 things:

1. Adds a tool and build task which triggers cswin32 code generation at build time instead of as a source generator. This enables it to generate code that uses other source generators.
2. Adds a mode to cswin32 which tells it to generate code that produces [LibraryImport] instead of [DllImport] and [GeneratedComInterface] instead of [ComImport].

The build task & CsWin32Generator.exe tool

The build task is a simple ToolTask wrapper which takes its properties and passes them along to the CsWin32Generator tool. The build task is netstandard2.0-targeted to minimize dependencies and enable it to work in msbuild and dotnet environments.

The CsWin32Generator is a net9 AnyCPU dotnet tool, since we know that anyone using cswin32 must have dotnet SDK on their machine and AnyCPU is much easier to package and run in the existing pipeline.

Because CsWin32Generator runs against net9, I updated the core CsWin32 itself to be multi-targeted so that the existing source generator is still netstandard but in the exe tool it runs net9. I also did this because for a while I was going to compile the tool as AOT but that proved to be more trouble than it was worth.

Updates to cswin32 itself.

The main idea of the change is that when running as a build task, we change our generated code to produce [GeneratedComInterface] instead of [ComImport]. Of course, it's not that simple since the source generators have different limitations/behaviors (some documented, others not).

The "allowMarshaling:true" mode which is the default, is the default for the build task. Conceptually we are using marshaling via source generators instead of the runtime. You can also set "allowMarshaling:false" to produce a fully blittable projection, but the point of this change is to enable the friendly marshaling mode in AOT.

Lots of changes needed to bridge the gaps.

• Com generators don't support InterfaceIsDual so any such interfaces need a [GeneratedComInterface] IDispatch to derive from. We generate one with placeholder vtable entries when needed.
• .NET Runtime has lots of automatic marshalling, including for enums and even structs with managed fields. [GeneratedComInterface] makes you be super explicit. In this change I have added an enum marshaler and a C#/WinRT type marshaler that are generated per-type when needed by the code generator and they are passed in [MarshalUsing(…)] attributes.
• I have not added a non-blittable struct marshaler yet. All structs with managed fields are forced to generate blittable entries. (e.g. instead of fields being object they would be unsafe IUnknown*). Thankfully cswin32 has a way to request that unmanaged versions of types get emitted even when allowMarshaling=true.
• IPropertyValue is a private type in C#/WinRT so when compiling against that projection, we have to translate that type to [MarshalAs(Interface)] object.
• .NET Runtime allowed unmanaged delegates to have marshaling on their parameters, like in/out/ref. When runtime marshaling is disabled, unmanaged delegates cannot have any marshaling. I changed cswin32 to generate pointer-typed parameters and updated the calling code to use fixed blocks instead (the friendly methods can still have out).
• ComImport let you have a property instead of get_Foo & put_Foo methods. GeneratedComInterface does not. We turn off property generation in sourcegenerators mode.
• For derived COM interfaces, ComImport made you declare all your base types and re-declare all the derived interfaces. GeneratedComInterface fixes this and you just declare your one base interface and only the new methods introduced on the interface.

Testing

I've written an extensive set of unit tests which run the cswin32generator tool, and using CSharpCompilation and CSharpGeneratorDriver, compile the generated code and verify that it has no warnings/diagnostics.

These new tests generate the entire Win32Metadata surface area using this new mode and it compiles. All the interesting cases I have turned into smaller test cases that take less time to run.

[AArnott]

First batch of comments, focusing on the infra rather than Cswin32 changes.

[AArnott]

All done with the tests and infra... next time I'll review CsWin32 itself. :)