[feature request] A way to compile and run raw `.cs` files from CLI (maybe extending `dotnet run`) in one-shot command

I'm proposing to extend `dotnet run` (or introduce a new command) to compile and run passed `.cs` files (along with a way to pass `dll`'s and `so` to be referenced) - so very similar to `python myscript.py` and `go run myscript.go`. By default it should be able to discover the assemblies stored in the selected SDK (or allowing to override the .NET version with a passed command-line switch), and also consider any passed `.dll`/`.so` search paths (and it can fail and ask user to add further command-line options like package references e.g. if it fails to discover some projects - like it is for python: if some module is not detected, python fails, requires the user to pip-install it and try again, so all essential csproj config options should be passable as command-line options). The working directory should be the current directory, and if any temp assemblies/binaries are created, their assembly location should be the current directory and not some `./bin/Debug/x64` - as this can break loading the `.so` files.

I think it would be a great addition to the https://github.com/dotnet/interactive direction and make .NET / C# stronger in the scripting (I also think it's time to also include a built-in REPL tool) and educational domains. This would make C# closer to the familiar-to-many `python` and `go` CLI workflow which do not require XML/JSON configs to just run a code snippet from CLI. Currently .NET tooling seems oriented to projects and having other tools (like Visual Studio) to prepare various configs, but for trying things out from CLI this can be almost insarmountably hard...

Currently `dotnet run` forces one to have a `.csproj` file which requires usage of other tools or knowledge of MSBuild intricacies (and its syntax is quite dated too). An alternative avenue is trying to use `csc.dll` directly, but it failed for me (if interested, please see context below) and is quite nasty to discover its path:
```shell
DOTNET_ROOT="$HOME/.dotnet"
DOTNETSDKVER=$("$DOTNET_ROOT/dotnet" --version)
DOTNETFWKVER=$("$DOTNET_ROOT/dotnet" --list-runtimes | grep Microsoft.NETCore.App | tail -n 1 | cut -d' ' -f2)
DOTNETLIBDIR="$DOTNET_ROOT/shared/Microsoft.NETCore.App/$DOTNETFWKVER"
"$DOTNET_ROOT/dotnet" "$DOTNET_ROOT/sdk/$DOTNETSDKVER/Roslyn/bincore/csc.dll" $(find "$DOTNETLIBDIR" -name "*.dll" -printf '-r:"%p" ') -target:executable -out:my.exe my.cs

# and for running the executable, it also requires manually adding `.runtimeconfig.json` (even if running is done via `dotnet my.exe`
```

---
Context:

I was trying to run a CppSharp which for some advanced setups asks to write+compile+run a small C# snippet which needs to reference the compiled CppSharp `.dll`'s including some native `.so` files.

As a newbie in the CLI world of .NET I found it currently quite convoluted. I ended up with something like this: https://github.com/vadimkantorov/tritonservercppsharp/blob/master/.github/workflows/tritonservercppsharp.yml#L36 which dumps a csproj file (I had a lot of troubles figuring out how to disable implicit source discovery and so on). Prior to that I was having problems with `.runtimeconfig.json` https://github.com/mono/CppSharp/issues/1860#issuecomment-2297062617 and with not being able to run a csc.dll-produced binary along with libraries built with `dotnet build`: https://github.com/mono/CppSharp/issues/1860#issuecomment-2297058536 it was failing to load the runtime and then scanned 10 different ICU data libraries to format the error.