[metalperformanceshaders] Fix MPSImageLanczosScale base class change

[spouliot]

Sadly this creates a breaking change since the ScaleTransform
property was re-introduced with an incorrect signature in the new
base class MPSImageScale

Unless someone has an idea how to avoid it (I don't see an option)
then we'll have to document it in the 15.7 release notes.

[monojenkins]

Build success

[rolfbjarne]

I'm fairly certain you can have the method in both classes with different signatures.

It's quite ugly, but it would not be a breaking binary change:

class MPSImageLanczosScale : MPSImageScale {
    public new virtual MPSScaleTransform? ScaleTransform { get; set; } // existing correct signature
}

class MPSImageScale {
    public virtual MPSScaleTransform ScaleTransform { get; set; } // old broken signature
}

Another issue is that the property with the correct signature has an incorrect implementation, the non-null setter path never calls the native _SetScaleTransform method to set the value, it writes the struct data to native memory, and then just immediately frees the native memory:

xamarin-macios/src/MetalPerformanceShaders/MPSImageLanczosScale.cs

Lines 23 to 33 in cfdf59d

	if (value.HasValue) {
	IntPtr ptr = Marshal.AllocHGlobal (size_of_scale_transform);
	try {
	Marshal.StructureToPtr<MPSScaleTransform> (value.Value, ptr, false);
	}
	finally {
	Marshal.FreeHGlobal (ptr);
	}
	} else {
	_SetScaleTransform (IntPtr.Zero);
	}

[spouliot]

@rolfbjarne good catch! it's not likely an API used commonly (which is good if we need to do a breaking change).

As for signature we want MPSImageScale to have the correct one too.

[spouliot]

There are also other subclasses of MPSImageScale that makes the above hack impossible to use :|

Adding it to it's base class, MPSUnaryImageKernel, seems more likely to cause further harm (at least confusion).

[monojenkins]

Build success