Add .NET Swift interop tooling components and layout

[kotlarmilos]

Description

This is the initial PR for the projection tooling which introduces the .NET Swift interop tooling components based on the Binding Tools for Swift and highlights the functionalities of the tool. Subsequent PRs will cover the process of projecting Swift types into .NET.

For importing Swift into .NET, the key components are presented, where they work together to allow the generation of C# bindings and Swift wrappers for interop. The process begins with the source Swift library, from which a module declaration is generated. Subsequently, the tool generates Swift wrappers and its module declaration for cases where direct P/Invoke is not possible. Finally, the tool generates C# bindings. For exporting .NET to Swift, the tool generates corresponding Swift and C# wrappers to enable type mapping.

Regarding distribution and validation, the tooling will be part of Xamarin publishing, shipped as NuGet package and accessible via .NET CLI. Validation will be achieved through supporting libraries and MAUI samples, as outlined in https://github.com/dotnet/runtime/issues/95636.

[kotlarmilos]

I have updated this PR according to the received feedback. The scope has been narrowed to focus on the general mechanisms of projections. For comprehensive details please refer to https://github.com/dotnet/runtimelab/pull/2512.

We've added validation steps for the projection tooling with required runtime support in https://github.com/dotnet/runtime/issues/95636. Additionally, there are proposed stages for evolving the tooling in https://github.com/dotnet/runtime/issues/95633.

Feel free to get involved and share your perspectives or feedback on any provided issue.

[kotlarmilos]

This PR should outline the general concepts of projection tooling. All details should be added to https://github.com/dotnet/runtimelab/pull/2512.

Please let me know if there is anything else that you think should be added here.

[agocke]

Could there be a little more elaboration on the IDisposable piece? My expectation is that we would use IDisposable for managed resources, but all the things mentioned as being cleaned up sound like they are native resources. That sounds like a better fit for destructors. What makes IDisposable necessary here?

[kotlarmilos]

Could there be a little more elaboration on the IDisposable piece? My expectation is that we would use IDisposable for managed resources, but all the things mentioned as being cleaned up sound like they are native resources. That sounds like a better fit for destructors. What makes IDisposable necessary here?

Good point. I've updated the docs to reflect the decision.

The IDisposable provides an explicit mechanism for releasing unmanaged resources. Destructors are managed by the GC and offer a way to release unmanaged resources when an object is collected by the GC. While destructors abstract away memory management from the user, the Idisposable pattern provides deterministic control over when resources and can lead to better performance as it prevents the need for GC collection cycles. The IDisposable pattern is the typical .NET approach for dealing with unmanaged resources and thus is selected as default option at initial stage. If it is determined that the IDisposable pattern introduces unnecessary overhead for users, and that destructors can adequately manage the release of unmanaged resources, appropriate updates to the memory management approach will be made.