Add AP to control TabControl Headers behavior

[corvinsz]

fixes #3863

This PR adds a new attached property (materialDesign:TabAssist.HeaderBehavior) to let consumers decide on how to display the headers of a TabControl.

Currently the headers are always contained inside of a ScrollViewer, which is not always ideal. Under certain circumstances the user is unable to click on "the next" tab, because it is simply not shown:

With the new AP TabControls can be forced to wrap their headers in a WrapPanel, e.g.: materialDesign:TabAssist.HeaderBehavior="Wrapping".
There is basically now a trigger in the ControlTemplate which swaps out the header of the TabControl.

Note

As of right now the AP can't be changed at runtime. Apparently applying the template when the property changes isn't enough. The TabControl sometimes doesn't show it's content when selecting a Tab after changing the materialDesign:TabAssist.HeaderBehavior. I would argue having the need of changing this AP at runtime is rather rare.

private static void OnHeaderBehaviorChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
    if (d is TabControl tabControl)
    {
        tabControl.ApplyTemplate();
    }
}

[Keboo]

Soerry for the delay on this. I think a better implementation would be to create a secondary style and/or control template for the TabControl that implements it with the WrapPanel. The default WPF behavior contradicts the material design behavior, so we want the current (horizontal scroll behavior) to be the default, but in cases like this we have often put in secondary styles that people can set if they want a different behavior.

[Keboo]

Rather than this grid with both sets of controls. What if we apply a style trigger to the ColorZone and swap out its child content based on the AP?

[corvinsz]

I'm going to create a new PR for this. The rebase was a little much