Raise the EffectiveViewPortChanged when a control is added to the tree that has already has a valid layout

[danwalmsley]

What does the pull request do?

Fix the raising of the EffectiveViewPortChanged event.

What is the current behavior?

If you add a control that expects the EffectiveViewPortChanged event to a tree that has already has a valid layout, it never receives the event, giving the initial value.

The reason is because when the listener is added

new EffectiveViewportChangedListener(
control,
CalculateEffectiveViewport(control));

    an initial value is calculated for the viewport.

When this is being added to a parent that has a size a size here is calculated.

Now when the actual layout pass happens

LayoutManager -> RaiseEffectiveViewportChanged()

var viewport = CalculateEffectiveViewport(l.Listener);

if (viewport != l.Viewport)
{
    l.Listener.RaiseEffectiveViewportChanged(new EffectiveViewportChangedEventArgs(viewport));
    l.Viewport = viewport;
}

viewport and l.Viewport are equal and the event is skipped.

What is the updated/expected behavior with this PR?

We now match the UWP behavior of raising the event.

How was the solution implemented (if it's not obvious)?

1. don't initialise the Listener ViewPort property.
2. make the Listener ViewPort property nullable, so that it has to raise it the first time.

This other PR updates the UWP tests that prove our behaviour is the same.
grokys/EffectiveBoundsTestsUWP#1

Checklist

• Added unit tests (if possible)?
• Added XML documentation to any related classes?
• Consider submitting a PR to https://github.com/AvaloniaUI/avalonia-docs with user documentation

Breaking changes

Obsoletions / Deprecations

Fixed issues