Use in-process GCM Avalonia-based UI helpers

[mjcheetham]

Feature description

Today GCM has an architecture that delegates all GUI prompting to (bundled) external executables, using WPF-based helpers on Windows and Avalonia UI helpers on Mac and Linux. Each host provider has it's own GUI helper executable, meaning we currently bundle four (GitHub.UI, GitLab.UI, Atlassian.Bitbucket.UI, git-credential-manager.ui [for generic auth]) helpers in addition to the core git-credential-manager CLI executable.

On Linux we use the "publish as a single-file" model for each of these executables, meaning we have a copy of the CLR included for each executable! That means five CLRs!

Now that the Avalonia UI-based GUI helpers have matured, we can look at dropping the WPF helpers and reduce the effort required to ship new GUI by 50% (we no longer need to do everything twice: once with WPF and once with Avalonia UI).

In addition, in a recent spike, I found that it may be possible to bring the Avalonia UI helpers in-process, with nearly zero net-new code. This would help reduce our installation footprint on Linux down to approximately 1/4 of the current size. The single executable model would also help decrease build times, and increase end-user performance since we no longer pay the process startup costs using external processes!

We need to be mindful that this change may result in a small increase in the Windows installation as we now bring in extra libraries used to support Avalonia UI, whereas previously we relied on WPF libraries as included with Windows 'for free'. This is expected to be minimal.

As for the current GUI extensibility model, we are not aware of any consumers, but it would not be much effort to keep the existing external process model, but now just default to using our in-process GUI options in the absence of external configuration. This still gives tools like VS or VSCode options to integrate native UI for GCM in the future, which has been something that has been raised recently (see #945).

Tasks

• Move shared and Avalonia UI helper logic from the <provider>.UI.* projects to the core projects <provider>
• Re-evaluate the possibility of trimming or Native AOT to further reduce file size and increase startup performance

[ldennington]

Dropping drop WPF from the goal - we don't believe we'll be able to meet the packaging/sizing constraints in Windows without WPF at this time.

[mjcheetham]

PR #1207

[mjcheetham]

We are keeping the WPF helpers around for at least one released version, as a fallback option.
The Avalonia UI (in proc) will be the default on all platforms.