Running Timer with CoreDispatcherScheduler in UWP app could result in freezing

Hello and thank you for using dotnet/reactive. Please select a category and detail your issue by answering the questions there:

#### Bug

> Which library version?

5.0

> What are the platform(s), environment(s) and related component version(s)?

Windows 10

> What is the use case or problem?

Creating a timer, which runs some background tasks; however, I accidentally create the timer using the CoreDispachScheduler instead of any other scheduler.

The timer will perform the job; however, when leaving the computer unattended, which results the app in the suspended state. The observable freezes the app when trying to resume it.

> What is the expected outcome?

the UWP app can resume.

> What is the actual outcome?

the UWP app cannot resume, just freezes, can maximize/minimize, but the rendering hangs, no control can be interacted

> What is the stacktrace of the exception(s) if any?
N/A

> Do you have a code snippet or project that reproduces the problem?

For testing, you can just try to do this:

```C#
// declare the scheduler in the class level
private readonly IScheduler _scheduler = new CoreDispatcherScheduler(CoreApplication.MainView.CoreWindow.Dispatcher);

// add a button, and wire the event handler
private void Button1Clicked(object sender, RoutedEventArgs e)
{
var timer = Observable
.Timer(TimeSpan.Zero, TimeSpan.FromSeconds(30), _scheduler)
.Subscribe(l =>
{
Debug.WriteLine("Timer running");
this.ResponseText.Text = $"{l} - {DateTime.Now} - Ticking";
});
}
```

The above code updates a `TextBlock` name `ResponseText`. Now minimize this window, leaves it for a few minutes.
Next, bring it back from task bar. You will see the app frozen and you can't interact with any other ui control.

If I use the `TaskPoolScheduler.Default`, it will not have such a problem. In theory, I agree, for a background task, I should not use the DispacheScheduler. But even I do, when the Dispatcher is in a suspended state, the timer should be paused automatically instead of freezing the app. It seems the suspended scheduler break the observable and cause the app fail to receive `WM_ACTIVATE`. Is this a bug in the framework?