Include `IssueId` and whether the issue could be fixed or not in the report file

I'm trying write some automation scripts to make formatting code using dotnet-format part of our build pipeline. If dotnet-format is unable to apply fixes (thus exiting with a non-zero exit code) I'd like to use the generated report file to log issues and abort the build.

Example PowerShell script illustrating what I am trying to do:
Click to expand

---

```powershell
dotnet format --report ".\report.json"

if ($LASTEXITCODE -ne 0) {
# There were unfixable issues.
$json = Get-Content ".\report.json" | Out-String | ConvertFrom-Json
$issues = $json |
Select-Object FilePath -ExpandProperty FileChanges |
Select-Object FilePath, LineNumber, CharNumber, FormatDescription

# Log issues to the console.
Write-Host "[ERROR] Unable to automatically fix $( $issues.Count ) issues:" -ForegroundColor Red
$issues |
%{ "[ERROR] $( $_.FilePath ):$( $_.LineNumber ):$( $_.CharNumber ): $( $_.FormatDescription )" } |
Write-Host -ForegroundColor Red

exit 1
}

# Proceed with the build as normal...
```

(Edit: I just discovered that dotnet-format only exits with a non-zero exit code when running with `--check`. To my knowledge, this means that there is no convenient way of programmatically detecting whether any issues were unfixable (aside from reading and parsing the standard output, or running dotnet-format twice).)

---

One problem I've encountered is that since the report file includes both fixed and unfixable issues, there is no way to programmatically tell which issues were unfixable. If the report included some sort of boolean property indicating whether a fix was applied, it would make it possible to isolate fixed issues from unfixable/not fixed issues. (When running with the `--check` option, all issues would be reported as not fixed.)

Another inconvenience is that the report file does not include the issue ID as a property. You can generally extract the issue ID from `FormatDescription` using regex, but it would be more convenient if it had its own property instead of being embedded in the message.

To summarize, my suggestion is to extend `FileChange` with the following properties:

```diff
public class FileChange
{
public int LineNumber { get; }

public int CharNumber { get; }
+
+ public string? IssueId { get; }

public string FormatDescription { get; }
+
+ public bool Fixed { get; }
}
```

This would make it easier for scripts to consume the report file and make decisions based on whether all issues were able to be automatically fixed or not.