Deserialize non-specified entries in GraphQLError

We recently upgraded the client from version 1.0.3 to 4.0.2 (quite an upgrade, I know).
One of the changes that we noticed is a change to the `GraphQLError` class.
[In version 1.0.3](https://github.com/graphql-dotnet/graphql-client/blob/v1.0.3/src/GraphQL.Common/Response/GraphQLError.cs), each `GraphQLError` held an `AdditonalEntries` dictionary which held raw fields on the response error.

[In version 4.0.2](https://github.com/graphql-dotnet/graphql-client/blob/master/src/GraphQL.Primitives/GraphQLError.cs), the `GraphQLError` class was changed.
Fields such as `path` and `extensions` were added to it and the `AdditionalEntries` was removed.

For example, here is an error received from Github:
```
{
"errors": [
{
"type": "INSUFFICIENT_SCOPES",
"locations": [
{
"line": 4,
"column": 28
}
],
"message": ""
}
]
}
```

In 1.0.3, the `type` field was part of the `AdditonalEntries` dictionary.
When running the same query in 4.0.2 and receiving the same error, it seems that the `type` field is **nowhere to be found**.

We had logic based on the value of that field.
For example, Github returns specific error types for different errors (INSUFFICIENT_SCOPES, PLAN_NOT_SUPPORTED, RATE_LIMITED, FORBIDDEN, and more).

So my questions are:
1. Did I miss a way of retrieving the `type` error field?
2. If not, any suggestion on how to handle the errors properly without that field?

Since GraphQL always returns a 200 OK and we need to detect errors based on the response, how do you suggest we map the specific errors now that this field is gone?
A possible solution is parsing the `message` field and running regular expressions on them, but that is really awkward and something I wish to avoid.

Thanks