Optimize DP setter codegen for Color, CornerRadius, and Thickness on WinAppSDK

[Sergio0694]

Follow-up to the previous XamlBindingHelper-based DP setter optimizations.

The latest version of WinAppSDK exposes three new static methods on Microsoft.UI.Xaml.Markup.XamlBindingHelper:

• SetPropertyFromColor(object, DependencyProperty, Windows.UI.Color)
• SetPropertyFromCornerRadius(object, DependencyProperty, Microsoft.UI.Xaml.CornerRadius)
• SetPropertyFromThickness(object, DependencyProperty, Microsoft.UI.Xaml.Thickness)

These extend the optimized setter path the generator already uses for other well-known WinRT-projected types, but they (1) only exist on WinAppSDK (the UWP Windows.UI.Xaml.Markup.XamlBindingHelper has no equivalent) and (2) were only added in a recent WinAppSDK release. Consumers on older WinAppSDK versions must therefore not get codegen that calls them.

What changed

• Execute.GetXamlBindingHelperSetMethodName now takes the current Compilation and the useWindowsUIXaml flag so it can probe the resolved XamlBindingHelper type for the new methods.
• A new private Execute.HasXamlBindingHelperMethod helper resolves Microsoft.UI.Xaml.Markup.XamlBindingHelper (via WellKnownTypeNames.XamlBindingHelper(useWindowsUIXaml: false)) and verifies the full static void Method(object, DependencyProperty, T) shape, where T matches a caller-supplied metadata name. The strict signature check guards against any future overload with the same name but a different shape.
• The well-known type-to-method tables are consolidated into two ReadOnlySpan<(string, string)> literals — one for the methods available on both UWP and WinAppSDK, and one for the new WinAppSDK-only methods. UWP short-circuits before the second loop, so no GetTypeByMetadataName work happens on the UWP path.
• The single call site in DependencyPropertyGenerator.cs flows useWindowsUIXaml and context.SemanticModel.Compilation to the helper using named arguments.

Correctness / incremental notes

• UWP (useWindowsUIXaml == true) is left completely untouched — the new code is gated behind !useWindowsUIXaml, and existing snapshot tests (which target UWP) are unaffected.
• The probe runs inside the existing ForAttributeWithMetadataNameAndOptions transform, which already takes a non-equatable GeneratorAttributeSyntaxContext and produces equatable output. The resulting method name flows through the existing equatable DependencyPropertyInfo.XamlBindingHelperSetMethodName string, so downstream output correctly invalidates when a project upgrades its WinAppSDK reference.
• Compilation.GetTypeByMetadataName is internally cached, and the probe only runs after the property type already matches one of the three new metadata names, so the per-property overhead is negligible.

Tests

No new tests are added: the new behavior depends on whether the host compilation references a WinAppSDK version that exposes these methods, and that cannot easily be toggled inside the existing snapshot test infrastructure. The change is purely additive on the WinAppSDK code path and leaves UWP/useWindowsUIXaml == true codegen unchanged, so existing test assertions continue to hold.

[MitchRazga]

On the "no new tests" note, WinUI 3 doesn't really seem to have good test coverage for XamlBindingHelper (or it just isn't public yet).
It shouldn't have to be the responsibility of the CommunityToolkit to cover these but maybe a few very simple
round-trip tests would be beneficial since some of these optimizations may have a different behavior than expected.

For example I don't think SetPropertyFromByte has actually ever worked as the name implies, or if the docs are just unclear.
It doesn't actually set a byte value, it looks like SetPropertyFromByteImpl calls CValueBoxer::BoxValue with a BYTE, but since CValueBoxer has no BYTE overload, and BOOLEAN is typedef BYTE, it binds the BOOLEAN one: box->SetBool(!!value). Meaning every non-zero byte is stored as true.

I'm happy to write some tests for this PR or in a follow up if you think they are worthwhile 😄

[Arlodotexe]

Reviewed the code line-by-line, no questions or critiques. @Sergio0694 If you've tested it yourself already via a local ProjectReference or via the PR feed, we're good to merge and ship to the Labs NuGet feed and prerelease packages on nuget.org.

[Arlodotexe]

Disabling auto-close to confirm it's been tested with OP, versions are derived from the date so we can only ship a package update once per day per component.

[Sergio0694]

Yeah I think I did test this back then. I'll merge this so I can rebase the other one and continue doing changes.