Handle error codes in authentication callbacks

**Is your feature request related to a problem? Please describe.**
I am trying to integrate custom authentication in Azure SWA, in my case Azure AD B2C, using the documentation provided at [Configure a custom OpenID Connect provider](https://docs.microsoft.com/en-us/azure/static-web-apps/authentication-custom?tabs=aad#configure-a-custom-openid-connect-provider). This works well when the user completes the authentication request and is redirected back to the application.

The problem for me occurs when the user either cancel the authentication request, or would like to initiate a different authentication request, which causes the authentication provider to return an error code to the authentication callback `/.auth/login//callback?error=&error_description=`.
The error code and message is displayed to the user as `{ code: 401, message: "..." }`, which is useful for debugging, but I would like to handle response somehow and have the user continue with the correct flow.

**Describe the solution you'd like**
If the user has cancelled the authentication, then I would like to redirect the user to a landing page.
If the user initiates a new authentication request, e.g "forgot password", then I would like to redirect the user to the new authentication request.

**Describe alternatives you've considered**
I tried to handle this by redirecting the callback to a custom page or api function, which could have functionality to handle the provided error, e.g:
```
{
"route": "/.auth/login//callback",
"redirect": "/handle-authentication-error"
}
```
Unfortunately I was unable to make this work. It seems that adding a redirect or rewrite route for the authentication callback would have no effect.

I also tried to have a more fine grained route, this would be preferred if possible, where I tried to redirect the user based on the query parameters provided to the authentication callback, e.g:
```
{
"route": "/.auth/login//callback?error=&error_description=*",
"redirect": "/.auth/login/"
}
```
This did also not work out, but I assume that could also be invalid use of wildcards in the route.