This fixes the problem decribed in #1054 but I think there's something wrong with the way we handle top level layout anyway and it's going to need refactoring soon.
(cherry picked from commit 7337a90fc1)
To do this needed to change behavior a little in that now binding errors update the target. Previously in the case of a binding error at the first node in the binding chain, we were converting the `BindingNotification` to `UnsetValue` which had the effect of updating the target value. Now we're passing the `BindingNotification` back, we need to make sure this happens. I believe this is the right thing to do as the behavior should be the same no matter where in the binding chain the error occurs. Data validation errors continue to not update the target.
1. Fixed some tests to expect `BindingNotification`s to be returned on a broken binding chain.
2. Changed logging of `BindingNotification`s - log at `Warning` level (instead of `Error`) except when the binding chain is broken at the root, in which case log at `Information` level. Do this to prevent flooding the output window when initializing.
If there's a `Command` binding for a `MenuItem` it will now swallow the `Click` event, meaning that the menu won't get closed. Listen for handled events too.
`AvaloniaPropertyAccessorPlugin` now checks that the requested property is available as a `AvaloniaProperty` on the target, and if not returns a `false` match. This means that the binding will be passed on to the `InpcPropertyAccessorPlugin`.
There was a problem in `WeakSubscriptionManager` in that an `AvaloniaObject` exposes 2 `PropertyChanged` events and `WeakSubscriptionManager` was picking up the `AvaloniaObject` one. Had to make `WeakSubscriptionManager.Subscribe` generic on the target parameter so that the requested event (`INotifyPropertyChanged.PropertyChanged`) was found instead.
danwalmsley
Nikita Tsukanov
Steven Kirk
Steven Kirk
Jeremy Koritzinsky