[Bug]: removing the reason of bindingRedirect doesn't trigger exe.config file to be regenerated

### Issue Description

When I add 2 references to 3rd party libraries, which have a version conflict, a bindingRedirect will be automatically added to the config file of the start-up project on the next msbuild.
But when then I remove one of the references, the config file is not regenerated on the next msbuild and still have a bindingRedirect.
A workaround is to call "msbuild /t:Rebuild" explicitly.

### Steps to Reproduce

Create a project of the type "Console application" in .Net Framework 4.7.2.
Add a default App.config file.
Add an assembly reference to ServiceStack.Redis.8.0.0 located locally.
Add an assembly reference to System.Runtime.CompilerServices.Unsafe.6.0.0 located locally.
So the csproj file has the following:

```

..\packages\ServiceStack.Redis.8.0.0\lib\net472\ServiceStack.Redis.dll

..\packages\System.Runtime.CompilerServices.Unsafe.6.0.0\lib\net461\System.Runtime.CompilerServices.Unsafe.dll

```
Execute msbuild in the project folder.

Intermediate result (expected): a file projectName.exe.config has the App.config content plus a bindingRedirect for System.Runtime.CompilerServices.Unsafe.
```

```

Remove the assembly reference to System.Runtime.CompilerServices.Unsafe.6.0.0.
Execute msbuild in the project folder.
[ConsoleApplication472.zip](https://github.com/dotnet/msbuild/files/14382376/ConsoleApplication472.zip)

### Expected Behavior

projectName.exe.config file should be regenerated and have no bindingRedirects. It should only contains the content of the original App.config file.

### Actual Behavior

projectName.exe.config's content remains unchanged (it was not regenerated from the previous msbuild call). It contains a bindingRedirect.

### Analysis

_No response_

### Versions & Configurations

MSBuild version 17.9.5+33de0b227 for .NET Framework
17.9.5.7608

.Net Framework tested: 4.7.2 and 4.8