Handle error events in HCS notifications.

[helsaawy]

The shim parses the JSON result document and handle the error events (via processHcsResult) returned by HCS calls (e.g.,vmcompute.HcsCreateComputeSystem), but ignores the JSON payload for notifications (which are either received from a processAsyncHcsResult in the appropriate system or process call in "internal.hcs", or via waitForNotification in waitBackground).

This leads to ambiguous failure errors (e.g., "The data is invalid.") that require ETW traces to track down the appropriate HCS logs, when the error events could have provided enough context to identify the issue.

Parse the notificationData JSON payload provided by HCS to the notificationWatcher callback into the appropriate hcsResult struct.

Validate that the JSON data matches the notification HResult.

Create a new error type (hcsResult) to handle both the error and events.

Since notification results are always subsequently passed to either make(System|Process)Error, update those functions to handle the events provided by hcsResult errors.

Since ErrorEvents are always converted to strings in the context of concatenating several of them together, add an
(*ErrorEvent).writeTo(*string.Builder) function to provide more efficient error string generation for (HCS|System|Process)Errors. Additionally, consolidate the joining and formatting of error events for those error types.

[rawahars]

With the upcoming projects, it is important that shim supports HCS V2 APIs. Also, HCS already wants to deprecate V1 APIs and therefore, it might be prudent for us to move too.

Should we have an effort to move shim from HCS V1 to V2?
If that's the case then this PR can be skipped and the logic can be correctly implemented in the new APIs.

[helsaawy]

Should we have an effort to move shim from HCS V1 to V2?

Ideally, yes, we should, but I am not sure the work involved would be easily addressed in a single PR, so this PR should be a good stopgap until we move entirely over to the computecore dlls