Log error when build is aborted

[Forgind]

Fixes #7287

Context

Cancelling a build can lead to a failed build with 0 warnings and 0 errors.

Changes Made

Ensured that we log an error when the build fails. From code inspection, this was at least one place where, if the build was cancelled, we might not log the error, though the build could still fail.

Testing

We don't have a repro for #7287, so I could not test this properly.

Notes

[Forgind]

Before:

Build started 9/19/2022 4:33:23 PM.
Attempting to cancel the build...

Build FAILED.
    0 Warning(s)
    0 Error(s)

After:

Build started 9/19/2022 4:34:19 PM.
Attempting to cancel the build...
MSBUILD : error MSB4188: Build was canceled.

Build FAILED.

  MSBUILD : error MSB4188: Build was canceled.

    0 Warning(s)
    1 Error(s)

[Forgind]

The failing tests made me concerned about having an assert here, and I am wondering whether I should really revert that part of this. Specifically, if you have a misauthored task that returns true but logs an error, and you're using a debug build of MSBuild, it will assert. That's bad, and they should fix it. If they're using a debug version of MSBuild on CI (does anyone do that?), the assert will look like a hang, and I imagine it would be very hard to track down. Together, those seem like a pretty unlikely scenario, but I think it would be extremely frustrating if someone did encounter that. What do you think? Revert or keep?

[rainersigwald]

if you have a misauthored task that returns true but logs an error, and you're using a debug build of MSBuild, it will assert

I think that's likely common enough that we should not have the assert.

[rainersigwald]

It looks like you reverted the BuildAbortedException error-code-scraping stuff. I prefer the revert there but I was asking you to change the BuildSubmission stuff back, since you said you didn't think it was critical to the change and it was nontrivial to understand the difference.