MSBuild does not cooperate with Restart Manager on Windows

### Summary

Lingering MSBuild processes lock .NET assembly files with MSBuild tasks, blocking the possibility of changing them.

### Background and Motivation

After `dotnet build` command completion, there are plenty of running `dotnet` processes launched with the following command line:

```
Module: dotnet.exe, 64-bit
Full path: C:\Program Files\dotnet\dotnet.exe

Command Line:
"C:\Program Files\dotnet\dotnet.exe" "C:\Program Files\dotnet\sdk\10.0.100\MSBuild.dll" /noautoresponse /nologo /nodemode:1 /nodeReuse:true /low:false
```

Those MSBuild processes are lingering around well after a build is completed.

If the build uses a 3rd party .DLL file with MSBuild tasks, the task file gets locked by one of the running `dotnet` processes. This creates problem for MSI installers that want to remove/modify that .DLL file.

### Proposed Feature

This would not pose a problem if MSBuild could cooperate with [Windows restart manager](https://learn.microsoft.com/en-us/windows/win32/rstmgr/about-restart-manager). However, as of MSBuild 18.0 / .NET SDK 10.0.100, MSBuild does not support its semantics. As a result, package installers have no clear way of tearing blocking MSBuild processes down, and this creates a painful experience for the end users if they happen to launch an installer soon enough after the last build.

### Alternative Designs

_No response_