dotnet fsi startup overhead surprisingly high

**Is your feature request related to a problem? Please describe.**

Startup time for `fsx` files is quite high. It might not matter if you are planning to do a large computation, but for small scripts, it seems to be routinely a few seconds, even for an empty fsx file with just `()` as code. I ran some benchmarks against similar python programs for comparison on a few machines, [inspired by this comment] (https://twitter.com/vilinski/status/1485188447639851012)
For small operating system tasks, running a tiny F# script would incur significant overhead, and it's a small barrier to starting up a quick REPL session/

Some tests I tried

### Hello world, windows, dotnet 6.0.101, git bash

```
$ cat hw.fsx
printfn "hello world"

$ time dotnet fsi hw.fsx
hello world

real 0m2.711s
user 0m0.000s
sys 0m0.031s

daz@DarrenHP MINGW64 /c/src/tmp
$ dotnet --version
6.0.101
```

For comparison, here is hello world python

```
$ time python hw.py
hello world

real 0m0.386s
user 0m0.000s
sys 0m0.031s

$ cat hw.py
print("hello world")
$ python --version
Python 3.9.2

```

It's not even about really running the F# code itself, similar tests get 1.8ish seconds for a completely empty .fsx file. Interesting, adding in just the expression `()` adds about another half second.

```
$ cat null.fsx
()

$ time dotnet fsi null.fsx

real 0m2.397s
user 0m0.000s
sys 0m0.030s

$ cat empty.fsx

$ time dotnet fsi empty.fsx

real 0m1.778s
user 0m0.000s
sys 0m0.031s
```

Again python seems to shrug off having nothing to do very quickly

```
$ cat null.py

$ time python null.py

real 0m0.162s
user 0m0.000s
sys 0m0.031s

```

Curiously, and this is hard ti time but if I run fsi without a script associated, and just hit ctrl-D really really quickly, I can be in and out of the reply in about a half-second (even with human reflexes), so there is something about an fsx file specifically which seems to slow things down. I guess that's good if you just want to play interactively

```
$ time dotnet fsi

Microsoft (R) F# Interactive version 12.0.0.0 for F# 6.0
Copyright (c) Microsoft Corporation. All Rights Reserved.

For help type #help;;

>
real 0m0.603s
user 0m0.000s
sys 0m0.031s
```

For comparison, on a fairly high end linux AWS instance (m4.4xlarge, 16 vCPU, 64 GiB ram), with dotnet 6.0.101

```
time ~/.dotnet/dotnet fsi null.fsx

real 0m1.702s
user 0m1.588s
sys 0m0.131s
```

**Describe the solution you'd like**

It's totally a qualitative thing, but overhead for commencing execution of an fsx file should comparable to the startup file for the reply (let's say a half second but closer to the python times of 0.2 seconds would be ideal)

**Describe alternatives you've considered**

This doesn't matter if you are compiling code but for running scripts, especially lots of small scripts back to back, the two seconds would be problematic and making fewer smaller scripts or a different scripting system would be the solution.

**Additional context**

I did a little profiling with `strace` and `strace -c` on a linux machine. I'm not sure this is super informative really - the total reported time in system calls is just 0.035 seconds. I suspect the time is more in userland but I'd have to profile the whole startup to see that bit. Trace output attached. There does seem to be a large pause in the output from strace for a second or so in the middle just watching it interactively but I don't think it's necessarily making a system call at that time.

[strace-output.txt](https://github.com/dotnet/fsharp/files/7921301/strace-output.txt)
[strace-c-output.txt](https://github.com/dotnet/fsharp/files/7921302/strace-c-output.txt)