Keep working directory clean in `dotnet run file.cs`

[jaredpar]

When running dotnet run app.cs there should be no binaries emitted to the current working directory. It should remain clean and artifact free. Instead we need to push these binaries out to another place on disk.

The location may need to change between operating system. The key criteria is that it's a location where permissions are expected to be restricted to the current user. Likely on Windows we will use Windows temp but on Linux may need to pick a place like SpecialFolder.LocalApplicationData

Under that folder we should create a sub-dir for dotnet-run-file.cs, possible just call it dotnet-run-file. Each file can then be a sub-dir which is named by taking a strong hash on the full file. This is just a rough sketch for us to think about, more than happy if the details change as we explore.

[baronfel]

We should take a look at how DOTNET_CLI_HOME should interact with this storage area.

[jjonescz]

I'm not sure how DOTNET_CLI_HOME should be incorporated here, currently I'm using this logic:

sdk/src/Cli/dotnet/Commands/Run/VirtualProjectBuildingCommand.cs

Lines 201 to 208 in cb2dfbb

	static string GetArtifactsPath(string entryPointFilePath)
	{
	// We want a location where permissions are expected to be restricted to the current user.
	var directory = RuntimeInformation.IsOSPlatform(OSPlatform.Windows)
	? Path.GetTempPath()
	: Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
	return Path.Join(directory, "dotnet", "runfile", Sha256Hasher.HashWithNormalizedCasing(entryPointFilePath));
	}

(If you'd like to just track exploring DOTNET_CLI_HOME interaction later, consider filing a separate issue as this one will get closed by my PR.)