Remove INotifyPropertyChanged boilerplate code

[JosefNemec]

Right now we generate a lot of boilerplate code for properties used in classes implementing INotifyPropertyChanged. Basically all classes that bind to UI views (essentially any class inheriting from our ObservableObject).

This is how it looks now:

private double viewportWidth = 1280;
public double ViewportWidth
{
    get => viewportWidth;
    set
    {
        viewportWidth = value;
        OnPropertyChanged();
    }
}

And that's excluding value comparison in setter if we wanted to remove unnecessary notifications in case that value doesn't actually change.

It should ideally look like this:

[NotifyProperty]
public double ViewportWidth { get; set; }

Or this since we sometimes need to notify more properties for single setter:

[NotifyProperty]
[NotifyProperty(Property = "ViewportHeight")]
public double ViewportWidth { get; set; }

Also it should be settable for the whole class in case we want to automatically notify all properties (with opt-out option for specific properties).

There are multiple ways to remove this boilerplate as far as I know:

• T4 templates. I have no experience with those and it looks like it would generate a lot temporary files. Here's an example.
• Fody's PropertyChanged module. Fody has a really weird license and I'm going to straight up reject it for that reason.
• PostSharp. I'm not sure if they support all scenarios I mentioned above.
• Aspect Injector. No idea about this one.
• Other methods like this and this.

Not matter what solution we choose it should support debugging of notify events. There are multiple areas of Playnite where performance can degrade drastically if unnecessary notify events are sent (for filter settings for example) and we should be able debug these cases easily.

[JosefNemec]

https://devblogs.microsoft.com/dotnet/introducing-c-source-generators/

[Logerfo]

This is a good example, but some work has to be done in order to achieve the feature of notifying multiple properties when one changes. I suppose migrating to .NET Core is required first and that's probably why you set them to the same milestone.

[bretthysuik]

CommunityToolkit.Mvvm uses attributes and source generators, is MIT-licensed, targets netstandard2.0, and is highly optimized.