Add option to `dotnet format` to format a single file provided on stdin

### Is your feature request related to a problem? Please describe.
I use a Git-compatible VCS called [Jujutsu](https://github.com/martinvonz/jj) (do try it, it's pretty great). This VCS has a command `jj fix` which is meant to run linters and formatters on changed files, possibly across many commits, with a single command.

`jj fix` requires a fix tool to behave like a Unix-style filter: The current file contents is passed to stdin, and the replacement contents is read from stdout. For example, the configuration for Prettier looks like this:

```toml
[fix.tools.prettier]
command = ["prettier", "--stdin-filepath", "$path"]
patterns = [ 'glob:"**/*.ts"' ]
```

For each changed file, this does something similar to:

```powershell
cat a.ts | prettier --stdin-filepath a.ts > a.ts
cat b.ts | prettier --stdin-filepath b.ts > b.ts
...
```

Unfortunately, `dotnet format` is incompatible with `jj fix` because `dotnet format`directly reads and writes files in the working copy. The `jj fix` command may operate on multiple commits, but it does not update the working copy between executions of the fix tool.

### Describe the solution you'd like
A mode for `dotnet format` which causes it to act like a filter. For example, the following command would output a formatted copy of `path/to/file.cs` on stdout but not overwrite any files:

```powershell
cat path/to/file.cs | dotnet format MySolution.sln --stdin
```

To support the hierarchical nature of EditorConfig files, it should also accept a `--stdin-filepath` option which tells the formatter which filename it should assume it's formatting:

```powershell
# reads .editorconfig files from ., ./path, and ./path/to
cat path/to/file.cs | dotnet format MySolution.sln --stdin --stdin-filepath path/to/file.cs
```

I am not sure if accepting the `[SOLUTION | PROJECT]` arg makes sense in this mode.

_Technically_, an `.editorconfig` file in a particular commit may be different than the `.editorconfig` that `dotnet format` would read from the working copy, and this could affect how `dotnet format` formats files. However, this problem would be rare so I think it's probably reasonable to disregard it.

It might be impossible to run analyzers this way, so restricting this to the `dotnet format whitespace` and `style` subcommand is reasonable.