Windows dark mode in .NET 10 build

[HebaruSan]

Background

• Windows 10 added a dark mode setting
• .NET 9 added experimental dark mode support for WinForms
• .NET 10 promoted that support to non-experimental

Motivation

CKAN users on Windows want a dark mode. (Mono's WinForms implementation provides a dark mode automatically if the user's system theme is dark, so Linux users have had this all along.) We've provided some custom registry keys to make the old WinForms system colors dark, but it would be better if this was automatic and looked nicer, which the .NET 10 dark mode achieves.

Changes

• The net8.0 build is updated to net10.0
  • Some references are updated to address supply chain warnings, but many others cannot be addressed
  • Some changes are made to handle updates to nullability support in libraries
  • Apparently the Form.Closing event is now replaced by FormClosing, so we've made that switch
• The net10.0-windows build is now published to a ckan-windows.exe file, which is attached to commits as an artifact and uploaded to releases and S3 for dev builds.
  To make this work:
  • We now get built files from the Windows build instead of the Ubuntu build (since ckan-windows.exe can only be built on Windows)
  • Since AltCover cannot handle testing in a different Windows container than the one that built the DLLs, test.yml is now eliminated and build.yml handles both building and testing in one step for both platforms
  • Now tests are run in Release mode instead of Debug
  • The autoupdater now looks for a remote file with the same name as the running process rather than just ckan.exe, which will still be the net481 build, since the ckan-windows.exe build would need to replace itself with the latest version of that same build
  • The SignPath config is updated to sign ckan-windows.exe
• When the net10.0-windows ckan-windows.exe build launches the GUI, if the registry key HKEY_CURRENT_USER\SOFTWARE\Microsoft\CurrentVersion\Themes\Personalize\AppsUseLightTheme is set to a value other than 1 (which is controlled by the display settings dark mode option), then GUI will start in dark mode:
  
  • The title bar is also made dark when in dark mode (this is a separate and independent API call 🤦)
  • ListViews with groups will have a somewhat lighter background than is the default in dark mode, to make the hard-coded-blue group headers readable:
    
• LinkLabels will use a new Util.LinkColorForBackColor() function to set their text color to a blend of blue and white when the background is dark (the default is a harder-to-read blue)
• The black-on-transparent icons used in various toolbars and treeviews such as in Unmanaged Files and the Relationships tab are now inverted when the background is dark:

  Relationships	Contents

• The flat toolstrip renderer is updated to work better by setting the gradient colors in our own custom color table, such that we can now also use it in Windows, eliminating the annoying gradient in menus and toolbars
• The borders of the main mod list column headers are restored so users can see where to click to resize them
• While working on the above, I noticed that while the "Check All" and "Check Recommendations" buttons on the choose recommendations screen disable and enable themselves when all applicable mods are or are not checked, the "Check Suggestions" button didn't. Now it does.

Important caveats

• In order to get Windows dark mode, users MUST use the ckan-windows.exe build, NOT the ckan.exe build!
  ckan.exe is built for .NET Framework 4.8.1, which does not have dark mode support for WinForms, but is possible to run with Mono, so this is the build that will be used for Linux.
  ckan-windows.exe is built for .NET 10, which does have dark mode support for WinForms, but is not possible to run with Mono.
• There will be no automatic switchover; the autoupdater will update users of previous releases to the ckan.exe version only (because this is already pre-determined and hard-coded by the code in the old releases), and they will have to download ckan-windows.exe on their own
  (But once users are on the ckan-windows.exe track, the autoupdater should keep them on it.)
  Maybe we can figure out a smoother way to handle this in the future.
• The new ckan-windows.exe build uses single-file mode, but not self-contained or trimmed. This allows us to still ship just one file (I do not want to receive support requests because somebody didn't copy one DLL out of fifty), but without it being 100+ MB.
  (The .NET Framework builds have always used ILRepack to produce one .exe file, but this does not work with .exe files on post-Framework .NET.)
  Trimming would be nice to shrink the build further, but when I tried enabling it, there were some very thorny errors to fix related to how to avoid dropping dependencies that are accessed via reflection. Leaving this as a possible future project.