Fix broken windows installer

[bdach]

Closes #26510.

Time for a rant.

Technically, this "broke" with 9e8d07d, but it is actually an end result of upstream behaviours that I am failing to find a better description for than "utterly broken".

Squirrel (the installer we use) has unit tests. Which is great, power to them. However, the method in which that testing is implemented leads to epic levels of WTF breakage.

To determine whether Squirrel is being tested right now, it is checking all currently loaded assemblies, and determining that if any loaded assembly contains the magic string of "NUNIT" - among others - it must be being tested right now.

If one assumes that there is no conceivable way that an NUnit assembly may be loaded without it being a test context, this may seem sane. Foreshadowing.

(Now, to avoid being hypocritical, we also do this, but we do this by checking if the entry assembly is an NUnit, which seems much saner, no?)

Now, why did this break with 9e8d07d specifically, you might wonder?

Well the reason is this line:

osu/osu.Desktop/NVAPI.cs

Line 183 in 3d3f58c

Logger.Log(success ? $"Threaded optimizations set to \"{value}\"!" : "Threaded optimizations set failed!");

Yes you are reading this correctly, it's not NVAPI anything itself that breaks this, it is a log statement. To be precise, what the log statement does to provoke this, is calling into framework. That causes the framework assembly to load, which transitively loads the nunit.framework assembly.

(If you ever find yourself wanting to find out this sort of cursed knowledge - I hope you never need to - you can run something along the lines of

dotnet-trace collect --providers Microsoft-Windows-DotNETRuntime:4 -- .\osu!.exe

then open the resulting trace in PerfView, and then search the Microsoft-Windows-DotNETRuntime/AssemblyLoader/Start log for the cursed assembly. In this case, the relevant entry said something along the lines of

HasStack="True"
ThreadID="23,924"
ProcessorNumber="0"
ClrInstanceID="6"
AssemblyName="nunit.framework, Version=3.13.3.0, Culture=neutral, PublicKeyToken=2638cd05610744eb"
AssemblyPath=""
RequestingAssembly="osu.Framework, Version=2024.113.0.0, Culture=neutral, PublicKeyToken=null"
AssemblyLoadContext="Default"
RequestingAssemblyLoadContext="Default"
ActivityID="/#21032/1/26/"

Either that or just comment the log line for kicks. But the above is much faster.)

Now, what happens if Squirrel "detects" that it is being "tested"? Well, it will refuse to close after executing the "hooks" defined via SquirrelAwareApp, and it will also refuse to create version shortcuts.

Sounds familiar, don't it?

There are days on which I tire of computers. Today is one of them.

[peppy]

We ran into similar cascading failures in stable, like a using statement in Program.cs to a dll which isn't yet downloaded causing a crash. We'll have to pay special attention to Program.cs changes going forward..