Bring Metal APIs to a common .NET TFM

[maxkatz6]

Description of Change

Currently all Metal related APIs are hardcoded to .NET iOS and .NET macOS TFM.
It makes it a bit more difficult to use these APIs, when consuming library either doesn't use these targets or just wants to abstract these calls without an extra TFM.

In Avalonia, for macOS specifically, we don't use "net8.0-macos" target, as all necessary AppKit API we call from our native library. Thus, we don't have typical .NET IMtlDevice and friends, instead we only have pointers.

This caused a problem on our side, but there is no problem that can't be solved with some reflection:https://github.com/AvaloniaUI/Avalonia/blob/master/src/Skia/Avalonia.Skia/Gpu/Metal/SkiaMetalApi.cs

From the API perspective, I think changes in this PR do make sense:

1. Bringing all metal APIs like CreateContext to common SkiaSharp TFM, but only exposing pointers.
2. Keep old API for backward compatibility.
3. Integrate old typed members with new IntPtr members, reducing chance of making a mistake (though, it's relatively low).

API Changes

Metal APIs backported to common TFM, but with IntPtr members.
Note: SkiaSharp.Views package API wasn't changed, as it would be way more involving.

Behavioral Changes

None.

Required skia PR

None.

PR Checklist

• Has tests (if omitted, state reason in description)
• Rebased on top of main at time of PR
• Merged related skia PRs
• Changes adhere to coding standard
• Updated documentation

Can be considered a backport candidate, but understandably 2.88 might have API freeze at this point.

[mattleibow]

Thanks for this PR.

I think both properties are OK to have. In some cases you already have the queue/device and just setting it is easy enough. A bit redundant to have both, but the way you set to null is fine.

If it gets too annoying, I am sure there is a way to get the type instance via the iOS APIs - just the way getting objects from the runtime is doing for everything else. But, I am not sure how useful it is.