[12.0] Target SkiaSharp 3.0. Drop 2.88 support

[maxkatz6]

What does the pull request do?

For the last year, 11.x builds were compatible with both 2.88 and 3.0 SkiaSharp versions.
Half a year ago, SkiaSharp 3.0 had first stable release.
And now it's time to drop 2.88 support on the Avalonia side.

Note, this PR is not going to be backported to 11.x versions.

How was the solution implemented (if it's not obvious)?

1. Bump version
2. Replace obsolete APIs with new alternatives. Primarily SKSamplingOptions.
3. New APIs for Metal instead of reflection

Breaking changes

Any app or dependency that uses SkiaSharp APIs that are not binary compatible with SkiaSharp 3.0 will break.
It should not affect majority of applications. And even with Skia dependent controls like LiveCharts2 are already compatible with SkiaSharp3.

Fixed issues

Closes #15503
Fixes #17735
Fixes #18677

[maxkatz6]

Based on https://github.com/mono/SkiaSharp/blob/2b3f5bf292e1c95dd5a8647ff3a49ebb59d4d770/binding/SkiaSharp/SKPaint.cs#L28

[rabbitism]

also this #18677

[drasticactions]

@maxkatz6 This PR doesn't work with iOS right now,

https://gist.github.com/drasticactions/e964b2445a55752b8618dc89359fc338

MetalPlatformGraphics.TryCreate returns null, leading to it being disposed, leading to a crash on startup. If you deploy the ControlCatalog.iOS project, you should hit it.

e. I think I figured it out. The code in that TryCreate method that calls GRContext.CreateMetal (which isn't used and is disposed when the method is returned) is causing it to short-circuit, leading to a native error. I don't believe this code is needed. The actual GRContext.CreateMetal is created elsewhere in SkiaMetalGpu after initialization, where if this context can't be created, it should blow up then.

If you replace that method with

    public static MetalPlatformGraphics? TryCreate()
    {
        var device = MTLDevice.SystemDefault;
        return device is null ? null : new MetalPlatformGraphics(device);
    }

It works.

e2. Adding my change and re-adding Catalyst TFM as a target, Catalyst also works (Although some input stuff would need to be looked at, like scroll wheels for the list didn't work.)

Catalyst.mp4

[kekekeks]

The iOS crash is a double dispose bug in SkiaSharp.

[maxkatz6]

e. I think I figured it out. The code in that TryCreate method that calls GRContext.CreateMetal (which isn't used and is disposed when the method is returned) is causing it to short-circuit, leading to a native error.

IIRC, this extra metal context was used to validate whether metal is working fine, or fallback to opengl otherwise. These were issues in 2.88 where it could return null (I think maccatalyst or tvos related?). Either way, it should be removed now.

Upd: yep, I even left a comment there for the future me:

Avalonia/src/iOS/Avalonia.iOS/Metal/MetalPlatformGraphics.cs

Lines 41 to 42 in 88bfecb

	// Can be null on macCatalyst because of older Skia bug.
	// Fixed in SkiaSharp 3.0

Definitely should remove it now.

[drasticactions]

With 7f1a4d1, it fixes the iOS/Catalyst SkiaSharp 3.x issue and I can use it there,

For #19028, I bumped my repro and the users repro to this version (on a different machine than what I originally had), built and ran it, and it worked. IMO we need more confirmation from them to make sure it works right on macOS 26 (since I was able to somehow get it working with no changes after originally get the same crash, and I'm not sure how I did that yet). But the changes to the bindings didn't regress it so I think it's safe in that context.