[Binding SG] Enable usage of private fields and properties in SetBinding path

[jkurdek]

Description of Change

The existing implementation of the SetBinding method cannot utilize private properties or fields in the getter, as the generated code is created in a separate class, making it unable to access these private members.

This PR addresses this limitation by introducing the capability to handle inaccessible fields and properties in the binding path through the generation of unsafe accessors.

---

Private Fields

private Button _button = new Button();

public MainPage()
{
   EntryB.SetBinding(Entry.TextProperty, static (MainPage mp) => mp._button.Text);
}

[UnsafeAccessor(UnsafeAccessorKind.Field, Name = "_button")]
private static extern ref Button GetUnsafeField<id>_button(MainPage source);

---

Private Properties

private Button Button {get; set;}

public MainPage()
{
   EntryB.SetBinding(Entry.TextProperty, static (MainPage mp) => mp.Button.Text);
}

[UnsafeAccessor(UnsafeAccessorKind.Method, Name = "get_Button")]
private static extern Button GetUnsafeProperty<id>Button(MainPage source);

[UnsafeAccessor(UnsafeAccessorKind.Method, Name = "set_Button")]
private static extern void SetUnsafeProperty<id>Button(MainPage source, Button value);

---

Issues Fixed

Depends on #23671
Fixes #23535

Limitations

This PR does NOT add support for usage of nested private types. This issue is tracked here: #23534. Currently unsafe accessors cannot be applied to private types. This may change with: dotnet/runtime#90081

[simonrozsival]

This looks very promising! I left a few comments.

[simonrozsival]

What will happen when the property doesn't have a setter? I would expect the compilation of the generated code to fail in that case. Let's cover that with a unit test + ideally let's not generate the unsafe property setter at all when there isn't a setter.

[jkurdek]

The compilation will not fail. UnsafeAccessor can be used to modify a value of readonly fields / properties.

[simonrozsival]

But when the property doesn't have a setter, there won't be any set_{{propertyName}} method 🤔 would that only crash at runtime if the unsafe setter method is called?

[jkurdek]

Oh sorry. I was fixated on fields. It will crush on runtime I believe: https://sharplab.io/#v2:C4LgTgrgdgNAJiA1AHwAICYCMBYAUKgBgAJVMA6AJWmAEsBbAUzIGEB7OgBxoBsGwBlPgDcaAYwYBnANx5ZuPKgDMJdEQAirVngDeeIvqIcwNIQENgDEpmIAVBgA9gRbQHMGwKQF883+X6UqRMzOegYBqAAsRACyABQAlCG4BkS+vgrKGFYA7Dqh+gDaAKpQEqYAZgwAgqLiEhKsYLElZZU1dQ1gANI0UHBk0e4AFqxwMEQAcqaMRAC8RABEbsAA+naOC/EAugqYAGxEDhZgUFbEAOLuLRUMAApgrBx8wACe68CxGqxEDRBg4vEZH5iqUbu1JJ1mqC2rUIY0en0BsNRuMpjN5gsJO41kdNjt8PtDo4+KdIkRBMBrpV7o9nm8jp9ND9WH9xONSMQzNwIAxAfkiPyMKp+bpkikDGYwEQ4HMiFAGAB3dSaBJA8UGClUu4PJ5gV7vWJjRamUybNXqqwATliCwAGmo1Gb+WkgA===

[simonrozsival]

Could we use Enviornment.NewLine here instead? https://learn.microsoft.com/en-us/dotnet/api/system.environment.newline?view=net-8.0

[jkurdek]

The symbol 'Environment' is banned for use by analyzers: Analyzers should not read their settings directly from environment variables(RS1035)

[jonathanpeppers]

At first, I was worried that we had to rely on [UnsafeAccessor] for this.

But reviewing the code example:

private Button _button = new Button();

public MainPage()
{
   SomeControl.SetBinding(Entry.TextProperty, static (MainPage mp) => mp._button.Text);
}

Without this change, you would have to do this:

private Button _button = new Button();

public Button Button => _button;

public MainPage()
{
   SomeControl.SetBinding(Entry.TextProperty, static (MainPage mp) => mp.Button.Text);
}

From a developer's perspective, they wouldn't understand why they would have to do this. So, I think we have to support private members?

Reviewing the code, there are several tests, etc. Looks good to me. 👍

[simonrozsival]

All failing tests are unrelated.