[Trimming] Fix trimming unfriendly usage of implicit operators through reflection

[simonrozsival]

MAUI uses implicit operators invoked via reflection in several places, for example:

• BindableProperty.TryConvert(...)
  • this codepath is not only used in bindings, but also when BindableObject.SetValue(...) is used
• StaticResourceExtension.ProvideValue(...)

Unfortunately, this pattern isn't trimming/AOT compatible and we cannot fix it with [DynamicallyAccessedMembers] (in some cases the type isn't known at compile time, such as in value.GetType().GetImplicitConversionOperator(...)). When app code is trimmed, some of the required implicit conversion operators might not be available at runtime leading to unexpected behavior.

Related to #18658, /cc @jonathanpeppers
Trimming warnings related to this issue are tracked in #19397

Possible solutions

1. Make the use of implicit operators obsolete and replace them with a different mechanism, such as IValueConverter
   • we could still keep the existing code with implicit operators, but it would be the responsibility of the developers to ensure the implicit operators are preserved by the trimmer using [Preserve] or [DynamicDependency]
   • this would be a breaking change to some apps
2. Globally disable trimming of implicit operators
   • this issue is very similar to an issue in System.Linq.Expressions - see Change trimming workaround for Linq.Expressions usage of custom operators runtime#79016 - cc @vitek-karas
   • if the discussed changes were implemented in the trimmer, we could use the new APIs to resolve this issue

[jonathanpeppers]

@StephaneDelcroix might want to comment, but I wouldn't think that implicit operators are commonly used.

For example, if the example is something like:

class MyType
{
    public string Text { get; set; }

    public static implicit operator string(MyType type) => type.Text;

    // NOTE: they could just use ToString()
}

If we document they have to use IValueConverter, that seems like an OK solution.

The only problem would be if type conversion of a BCL type is using an implicit operator by chance, and we didn't know it. In that case, we can probably add a strongly-typed code path for that conversion.

[simonrozsival]

Implementation was merged into the net9.0 branch