Remove System.Linq.Expressions usages in ReflectionClrPropertyInfo

[MrJul]

What does the pull request do?

This PR removes the System.Linq.Expressions usages in ReflectionClrPropertyInfo by using standard reflection instead.
With NativeAOT on win-x64, this removes 446 KB of native code.

Rationale

Expressions were probably used for performance in the past for standard property accesses, but it turns out this class is almost unused nowadays.

The only code path creating a ReflectionClrPropertyInfo is in StaticResourceExtension:

Avalonia/src/Markup/Avalonia.Markup.Xaml/MarkupExtensions/StaticResourceExtension.cs

Line 38 in b1489aa

PropertyInfo pi => new Avalonia.Data.Core.ReflectionClrPropertyInfo(pi),

This is never hit by the XamlCompiler, which provides a ClrPropertyInfo directly if StaticResource is used on a standard CLR property. The only way to get through this is to pass a System.Reflection.PropertyInfo manually to StaticResourceExtension.ProvideValue.

Plus, expressions are interpreted on platform where dynamic code isn't allowed, making them slower than standard reflection in this case.

[avaloniaui-bot]

You can test this PR using the following package version. 11.2.999-cibuild0050818-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[maxkatz6]

Nice.

I was considering playing around .NET feature flags, including Trimming Definition files which can be configured to replace specific properties with const stubs.

Something like bool IsReflectionBindingEnabled => AppContext.TryGetSwitch("Avalonia.Markup.Data.IsReflectionBindingEnabled"), which then can be replaced with const "false" value, when we have AOT build with compiled bindings enabled. Or when reflection bindings were explicitly disabled by another property.

This way, whole reflection binding subsystem could be trimmed out.

See https://github.com/dotnet/runtime/blob/main/docs/workflow/trimming/ILLink-files.md#illinksubstitutionsxml

[MrJul]

Having that switch would indeed be nice.

I think we can wait for .NET 9's new feature attributes (which I saw you discussing in the past), this would make implementation easier, not even requiring the extra XML file.