dotnet run: Allow overriding single‑file “runfile” cache location for sandbox/container/LLM scenarios

[audacode]

Description

With the new single‑file “dotnet run app.cs” feature, the CLI auto‑generates a temp project under the user home
(XDG_DATA_HOME/DOTNET_CLI_HOME). In locked‑down or sandboxed workflows (e.g. LLM‑CLI, agent containers without home write), this write fails:
Unhandled exception: Access to the path '/home/…/.local/share/dotnet/runfile/…' is denied.

Repro

```bash
# simple repro on Linux
echo 'Console.WriteLine("Hello World");' > app.cs
dotnet run app.cs

Note: Obviously you will only see an error if "codex" or some other sandboxed LLM agent attempts to write that code.

Current workaround

Setting DOTNET_CLI_HOME or XDG_DATA_HOME to a project‑local folder avoids the error, but also relocates all CLI data (NuGet cache, global tools, telemetry) into that directory.

Proposal

Introduce an option/flag (e.g. --runfile-cache-dir) or an env‑var (e.g. DOTNET_RUNFILE_CACHE) so that only the single‑file run cache is redirected, leaving the rest of the CLI user data undisturbed.

Environment

.NET SDK: 10.0.100-preview.5
OS: Ubuntu 22.04 (or equivalent)

[jjonescz]

Similar to #49130. Try adding #:property ArtifactsPath=some/path. Or you can specify that property in a Directory.Build.props so it has an effect on all your file-based apps in the folder.