Remove unnecessary file check for CLI arguments

[straight-shoota]

Resolves #13849

This patch momentarily degrades the error UX because read errors do not mention which file they appear on. That should improve with #13852 though, so I'm not taking any extra measures here.

[HertzDevil]

What happens if there is a compilation error and the compiler tries to read the source code again? (This isn't exclusive to those files of course, it more or less broke eval and --stdin-filename already)

[straight-shoota]

Well, then it may not be able to read the source code. But that's not a big deal. It's the same when eval reads from stdin.
I suppose we could consider improvements to that (such as keeping non-file sources in memory - or maybe just all source?).
But I don't think it's really important. These are likely used for rather trivial entrypoint code where source reference shouldn't matter much. It shouldn't hold back the possibility to use these other file types as input.

[HertzDevil]

We do keep them in memory somewhere, the compiler just doesn't use them yet. My main concern here is whether a blocking read is possible simply from showing a compilation error, making it indistinguishable from an infinite loop

[straight-shoota]

No, that can't happen. Every time the compiler reloads a raw source, there's an explicit File.file? check.