feat: add auto updater

[deansheather]

Adds an auto updater utility using NetSparkle.

Most of the UI matches the way it's done in NetSparkle for the built-in UIs (I referenced the Avalonia and WPF ones mostly), including most of the copy and implementation (incl. quirks). I did this in case we ever want to contribute this upstream. The only major difference is how I handle the release notes stuff.

For release notes, I use the <description> tag to generate HTML for the web view. There's a hardcoded """template""" in the source code and a copy of sindresorhus/github-markdown-css in the repo that gets included as an asset in the binary. This matches what we do on macOS but diverges from the way NetSparkle does release notes rendering using <sparkle:releaseNotesUrl> (or something like that).

• Adds a button to the right click context menu on the tray icon for checking for updates
• Adds custom UIs for all parts of the updater
• Implements "action" notifications with a click handler into UserNotifier
• Adds Serilog output to the debug output window in VS in DEBUG builds

TODO:

• App cast generation script
• Release pipeline modifications
• Generate secret key and add to repo secrets
• Publish initial 0.5.0 version manually
• Set final security and update source related settings in NetSparkle

Follow up:

• Integrate into the settings UI, add controls for whether it should automatically check for updates etc.

Closes #122
Closes coder/internal#703 (thanks Blink)

[spikecurtis]

I like the IDispatchQueueManager idea, but seems like this could just extend the TrayWindow and have it be the IDispatchQueueManager, rather than having it on the App and having to deal with the fact that it might be null.

We have the TrayWindow as a "transient" in the dependency injection right now, but the App creates an instance that it holds forever, so we are lying to ourselves about it being transient.

[deansheather]

The problem with this is if we define it as a singleton the DI instance tries to create it outside of the UI thread, which will crash the app. That's why all of the stuff that must be instantiated on the UI thread is marked transient, even if it typically only gets instantiated once.

[spikecurtis]

This shit is so dumb.

Q: How do you get on the main UI thread?

A: You need a DispatcherQueue.

Q: How do you get a DispatcherQueue?

A: You have to get it from a UI Window

Q: How do you get a UI Window?

A: You have to create it from the main UI thread.

Should we be moving all this initialization of dependencies to OnLaunched instead so it's on the main UI thread?

[deansheather]

truly a classic Microsoft® Moment™

We could try doing that. I don't know what the DI behavior will be for a singleton <IDispatcherQueueManager, TrayWindow> if it can still be accessed as both IDispatcherQueueManager and TrayWindow, but I'll give it a shot

[deansheather]

If I move all the instantiation to OnLaunched then all of the properties in App need to become nullable which seems worse, so I think I'll just stick to a method like this. I will make App itself be the IDispatcherQueueManager though which seems a lot nicer.

[spikecurtis]

Cool cool.

[deansheather]

thanks blink lmfao