Dependency resolution for scripts in VS editor incorrectly affects execution behaviour of other "dotnet fsi"

1. Create a script containing this

```
#r "nuget: TorchSharp-cpu, 0.93.6"

open TorchSharp

torch.randn(10)

#r "nuget: TorchSharp-cpu, 0.93.5"
```

2. Start Visual Studio 2022 and execute the first three lines of the script. A crash occurs. Version 0.93.5 of the native DLLs are being used in the `dotnet fsi` session even though we've never sent them across to that process as input text.

3. Comment out the last line, reset the F# Interactive session and re-run the first three lines of the script. The crash still occurs. Version 0.93.5 of the native DLLs are still being used! So editing in the editor hasn't corrected or removed the editor state.

4. Leave the last line commented out, restart Visual Studio and run the first three lines of the script. No crash. Version 0.93.6 of the native DLLs are now being used in the `dotnet fsi` session.

Here, in steps 1, 2 and 3, the fact that we even **edit** a file with the extra ``#r "nuget: TorchSharp-cpu, 0.93.5"`` at the end seems to create some state on disk (a temporary working directory, project file etc.) regarding the resolution for (native?) assemblies on disk. This state must also be being used by the `dotnet fsi` even though it's not even seen the full editor text!

Once we exit and restart VS at step 4., this state must have be cleaned up by the exit of VS (temporary working directories deleted). Now the editor analysis now never encounters the ``#r "nuget: TorchSharp-cpu, 0.93.5"`` and everything works and is consistent.

There is clearly some problem with native resolution using false information in some contexts, and resolutions from one (editing) session actually affecting resolution during execution.