New Dialog/Drawer/MessageBox option: StyleClass

[rabbitism]

This is the feature requested by multiple community users, such as #422
这是一个社区用户一直想要的功能，详见 #422

In general, we don't want to add a huge number of options for user to customize each button's content, order, foreground, background etc. For me this is a bad design in traditional XAML framework because they cannot touch the elements inside template easily. In Avalonia we do have the ability to customize template elements, so this new option can help you to apply a predefined style for Default Dialog and MessageBox.
Ursa整体上不希望将Dialog option 设计得过于复杂，例如为每个按钮的文字、位置、颜色等增加配置项。对于我来说，这是其他XAML框架的设计问题，因为在WPF等框架中不能方便地访问控件模板内的内容，他们别无选择。在Avalonia中我们有更改控件模板元素的能力，因此我们只需要为Dialog传入一个Class，即可将定义好的样式应用在上面。

How to use

使用方法

1. Define a special style for dialog with Classes selector, customize template elements. 在Dialog出现的地方定义样式，对其内部的元素进行自定义
   Example 例如：

        <Style Selector="u|DefaultDialogWindow.Custom">
            <Style Selector="^ /template/ Button#PART_OKButton">
                <Setter Property="Content" Value="CUSTOM"/>
            </Style>
        </Style>

2. Use Custom as the StyleClass when you invoke a Dialog. 在调用Dialog的时候将Custom作为StyleClass参数

The new created Dialog will have this Style applied. 新创建的Dialog就会应用此样式

Where to define the Style?

样式应该在哪里定义

1. For Dialog Window and MessageBox, the style should be defined in Application level 对于窗体对话框及MessageBox，应该定义在应用级别。
2. For Overlay Dialog, Ovelay MessageBox and Drawer, the style should be defined in the OverlayDialogHost or the host's parent or Application level. 对于Overlay模式的Dialog、MessageBox和Drawer，应该定义在OverlayDialogHost或其父级元素上，或者应用级别。

To help you set Style class for template elements inside a style, We exposed a ClassHelper.Classes as attached property. You should limit this usage, and keep it static. It is your responsibility to avoid loop style activation.
为了方便用户在Style中为模板元素应用样式类，我们暴露了ClassHelper.Classes作为依赖属性。你应该谨慎使用这一功能，并确保设计的样式不会出现循环触发问题。

Breaking Changes

破坏性更新

This pull request introduced a binary breaking change (no code breaking change). that IDialogContext interface is moved to another assembly. Developer needs to re-compile your application to include this dependency.

这个PR引入了一个破坏性更新，IDialogContext移入了另一个assembly。开发者升级后需要重新编译项目（无需修改代码）。

[rabbitism]

@dameng324 @genment please help to review.

[dameng324]

代码本身我看不出有什么问题，但我不太喜欢这样的设计。

1. 使用过程有些过于复杂，而且能定制的内容也比较有限（比如无法指定按钮的顺序），如果不查阅文档，用户将不知道如何使用这个功能，以及如何编写Selector，尤其是考虑到目前ursa的文档相当不完整。
2. OverlayDialog的样式必须定义在OverlayDialogHost或其父元素中，通常与实际使用的代码位置相隔甚远，这通常会带来一些维护性的问题。

个人看法，仅供参考。

[rabbitism]

代码本身我看不出有什么问题，但我不太喜欢这样的设计。

1. 使用过程有些过于复杂，而且能定制的内容也比较有限（比如无法指定按钮的顺序），如果不查阅文档，用户将不知道如何使用这个功能，以及如何编写Selector，尤其是考虑到目前ursa的文档相当不完整。
2. OverlayDialog的样式必须定义在OverlayDialogHost或其父元素中，通常与实际使用的代码位置相隔甚远，这通常会带来一些维护性的问题。

个人看法，仅供参考。

那我已经迷茫了，这个API应该设计成什么样子？

[dameng324]

我觉得有YesContent,NoContent,OkContent,CancelContent这几个作为Option传入已经基本够用了，API也简单明了。

更复杂的可以考虑将这些东西放到一个ViewModel中（如Title/Icon/Button内容），用户可以传递这个viewmodel实例进去，Ursa将这个ViewModel实例绑定到View中。

仅供参考。

[rabbitism]

我觉得有YesContent,NoContent,OkContent,CancelContent这几个作为Option传入已经基本够用了，API也简单明了。

更复杂的可以考虑将这些东西放到一个ViewModel中（如Title/Icon/Button内容），用户可以传递这个viewmodel实例进去，Ursa将这个ViewModel实例绑定到View中。

仅供参考。

基本不太可行，因为从此我会陷入和社区无尽的争吵：“为什么Content可以作为options而XX不能作为options呢？”

[genment]

我也觉得这个使用方法有点复杂。在不更改现有Dialog/Drawer/MessageBox的前提下，增加新的控件的可行性如何？参考 FluentAvalonia 的做法？
我在 #422 的回复

[rabbitism]

The PR itself solves many issues, although not satisfying #422 . Will leave that open, and merge this one.