Make so elmish update and cmd loop can run on non-ui thread

[marner2]

The basic implementation of this PR would be to invoke all calls to the underlying dispatch on one thread, then invoke all calls to UpdateViewModel on the UI thread associated with the window.

However, WPF expects events to raise NotifyPropertyChanged events before they exit, otherwise things like textboxes will "reset" following the disconnected update coming from the elmish update thread. This causes, for instance, the cursor to jump to a different location as you are typing. This means that we cannot simply invoke the dispatch calls coming from WPF in an async manner - we must block that call until the elmish update thread has processed that update and generated NotifyPropertyChanged events. This block is ok, because any dispatch calls from the non-ui thread will dispatch the UI update asyncronously.

One of the optimizations is to skip UpdateViewModel invocations if there is a pending UI update. This is ok, because calls to this function are transitive (skipping one in the middle still results in the same final state).

EDIT: Added a sample project that illustrates the threading capability and how to use it.

[TysonMN]

This means that we cannot simply invoke the dispatch calls coming from WPF in an async manner - we must block that call until the elmish update thread has processed that update and generated NotifyPropertyChanged events.

What is the advantage of doing work in another thread while the UI thread is blocked compared to doing that work on the UI thread instead of blocking?

[marner2]

@TysonMN

What is the advantage of doing work in another thread while the UI thread is blocked compared to doing that work on the UI thread instead of blocking?

If you are only updating the model from actions coming from the UI, there is none. However if you have subscriptions, you can guarantee that when you dispatch from a subscription, the update to the model always happens right away no matter what is happening on the UI thread. This has two potential advantages:

• If the update function generates elmish commands, those commands will always get generated and processed immediately on this background thread even if the UI is locked for some reason (maybe overwhelming updates to the view model). In our project's case, this is important because we are using the model state to emit instructions to a machine as well as update the UI state. We don't want that to slow down if the UI is processing something.
• If you get a bunch of UI updates "stacked up," you can safely drop the intermediate queue of updates to the UI since they are all bindings, and skipping an intermediate state will still leave the UI in the correct state (the transformation is stateless). I'm not doing that here, except that I drop updates while a UI update is pending.

There may be a gotcha with skipping updates and the captured model getting applied to the view model. Ideally we would always grab the latest model each time, so if we execute them "out of order" it doesn't result in an older one getting applied last (especially in the ui dispatch case).