Apply CallFuncConsideringUIThreads as possible as I can

[kenjiuno]

There are code fragments using ShowsUIOnMainThread instead of CallFuncConsideringUIThreads.

• ShowUpdateAvailableWindow
• CreateAndShowProgressWindow

Apply CallFuncConsideringUIThreads call as possible as they can.

[Deadpikle]

Hey, thank you for sending in this PR. I'm holding off on it for now until I figure out what to do about the various threading issues in this lib, since they might require more extensive changes. I really appreciate it :-) Not closing for now until I have time to look at it more closely. Thanks!

[Deadpikle]

Want to say "thanks" for this — I am incorporating this into some UI/threading rework now. I probably won't accept this PR as-is as I've further tweaked things, but it was helpful, so I'll try to add you as a co-author on the actual commit where the similar work is done so you get credit. :-)

In short: Thank you!

[Deadpikle]

I'm going to close this just for clarity for others. Want to say thank you again (Thank you!) - I did end up using this in #609, but as I kept working, I decided to take a simplification step and entirely remove the core lib's CallFuncConsideringUIThreads. Basically, users will handle their own multithreaded environments, and if they want to use NetSparkle's built-in UI's out of the box, the core lib assumes that it is on the main thread. I built a sample to show users how to use the built-in UI's with a multi-threaded WinForms app, too.

(Right now, as of this comment, there IS a bug where the worker thread for the start loop doesn't call back to the main UI thread. I'm going to make it so the worker thread calls back to the SyncronizationContext for things, but that'll be about it. Will fix that bug soon in #609.)

[Deadpikle]

Oh, and since I won't be squashing the PR into a single commit, and I did add you as a co-author to one commit, you will still get credit for the work. :-)