Propagate HTTP status code on error instances thrown by authorize and refresh calls

## Issue
It seems that the error object thrown by `authorize` and `refresh` calls on failures do not include the HTTP status code for errors returned by the IdP.
In case of iOS, the status code could somehow still be retrieved if you do `error?.userInfo?.NSUnderlyingError?.code` (not sure if that's recommended) but for android there's no trace of HTTP response in the object.

See the error object structure for Android and iOS for failed `refresh` call.

##### Android error
```json
{
"code": "invalid_grant",
"column": 51,
"line": 1579,
"message": "The provided authorization grant (e.g., authorization code, resource owner credentials) or refresh token is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client.",
"nativeStackAndroid": [
{
"class": "net.openid.appauth.AuthorizationService$TokenRequestTask",
"file": "AuthorizationService.java",
"lineNumber": 659,
"methodName": "onPostExecute"
},
{
"class": "net.openid.appauth.AuthorizationService$TokenRequestTask",
"file": "AuthorizationService.java",
"lineNumber": 564,
"methodName": "onPostExecute"
},
{
"class": "android.os.AsyncTask",
"file": "AsyncTask.java",
"lineNumber": 771,
"methodName": "finish"
},
{
"class": "android.os.AsyncTask",
"file": "AsyncTask.java",
"lineNumber": 199,
"methodName": "access$900"
},
{
"class": "android.os.AsyncTask$InternalHandler",
"file": "AsyncTask.java",
"lineNumber": 788,
"methodName": "handleMessage"
},
{
"class": "android.os.Handler",
"file": "Handler.java",
"lineNumber": 106,
"methodName": "dispatchMessage"
},
{
"class": "android.os.Looper",
"file": "Looper.java",
"lineNumber": 223,
"methodName": "loop"
},
{
"class": "android.app.ActivityThread",
"file": "ActivityThread.java",
"lineNumber": 7656,
"methodName": "main"
},
{
"class": "java.lang.reflect.Method",
"file": "Method.java",
"lineNumber": -2,
"methodName": "invoke"
},
{
"class": "com.android.internal.os.RuntimeInit$MethodAndArgsCaller",
"file": "RuntimeInit.java",
"lineNumber": 592,
"methodName": "run"
},
{
"class": "com.android.internal.os.ZygoteInit",
"file": "ZygoteInit.java",
"lineNumber": 947,
"methodName": "main"
}
],
"userInfo": null
}
```
##### iOS error
```
{
code: 'invalid_grant',
domain: 'org.openid.appauth.oauth_token',
message:
'The provided authorization grant (e.g., authorization code, resource owner credentials) or refresh token is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client.',
nativeStackIOS: [Array],
userInfo: {
NSLocalizedDescription:
'invalid_grant: The provided authorization grant (e.g., authorization code, resource owner credentials) or refresh token is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client.',
NSUnderlyingError: {
code: '400',
domain: 'org.openid.appauth.remote-http',
message: 'underlying error',
nativeStackIOS: [Array],
userInfo: [Object],
},
OIDOAuthErrorResponseErrorKey: {
error: 'invalid_grant',
error_description:
'The provided authorization grant (e.g., authorization code, resource owner credentials) or refresh token is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client.',
},
},
}
```

**Note:** for iOS, it is possible to get the code with `error?.userInfo?.NSUnderlyingError?.code` but it's platform specific.

---

## Proposal
I'd propose introducing an additional parameter `status` or `statusCode` in the error object giving us a standard way to get the HTTP status code returned by the IdP.

Let me know if you have a better idea. We can do a PR, if this is agreeable.

## Environment

* **Your Identity Provider**: `e.g. Ory Hydra`
* **Platform that you're experiencing the issue on**: `both`

Beginne damit nachzuverfolgen, wie die authorize- und refresh-Aufrufe Fehler durch die Android- und iOS-Bridges weitergeben, und vergleiche die im Issue gezeigten Fehlerobjekte. Die Aufgabe ist erledigt, wenn beide Plattformen den HTTP-Statuscode des IdP über eine standardisierte Fehlereigenschaft statt über plattformspezifische userInfo-Daten bereitstellen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.