Authorization Error Response: technical implementation details

The purpose of this issue is to expand on the topic of issue #368, which contains a brief description of a missing feature without including a full suggestion on how to implement it.

To contextualize the changes required by a full resolution of issue #368, we include a summary of the current authentication flows follows as described in the diagram described in [the italian specs](https://italia.github.io/eudi-wallet-it-docs/versione-corrente/en/relying-party-solution.html), which can be summarized as:

1. a pre authentication / login begin step, where either a QR code is displayer (cross device flow) or the wallet app is inoked via deep link in the user smartphone; the http handler associated to this behaviour is this
https://github.com/italia/eudi-wallet-it-python/blob/0bb0d986b3daf55ae76dc1cf115bc5de6543e85d/pyeudiw/satosa/default/openid4vp_backend.py#L219
1.1. in case of cross device flow, a javascript is polling on the /status endpoint; the primary purpose of this polling is to notify when step 3. is finished. https://github.com/italia/eudi-wallet-it-python/blob/0bb0d986b3daf55ae76dc1cf115bc5de6543e85d/pyeudiw/satosa/default/openid4vp_backend.py#L356
2. a "jar" request step: the wallet calls via HTTP request the url in the QR code (or in the deep link) to obtain the authentication request jwt that includes, in the claims, the oauth request performed by the RP toward the Wallet; the http handler associated to this behaviour is this
https://github.com/italia/eudi-wallet-it-python/blob/0bb0d986b3daf55ae76dc1cf115bc5de6543e85d/pyeudiw/satosa/default/openid4vp_backend.py#L219
3. an authorizatin response step: the wallet sends the to the wallet the user digital credential via an HTTP; the handler associated to that endpoint is this https://github.com/italia/eudi-wallet-it-python/blob/0bb0d986b3daf55ae76dc1cf115bc5de6543e85d/pyeudiw/satosa/default/response_handler.py#L94
the response to this endpoint is either
3.1 [Cross Device Flow] 200 Ok response; then the /status endpoint will finally get an ok response containing a redirect URL in its body (that is invoked by the user agent) to go on with step 4.
3.2 [Same Device Flow] 200 Ok with a redirect url to be invoked at step 4.
4. The user agent invoked the redirect_url (sometimes called response_uri in the italian specs), which in case of a positive outcome will pass the user digital credential to the satosa core to go on; the HTTP handler associated to that endpoint is this one https://github.com/italia/eudi-wallet-it-python/blob/0bb0d986b3daf55ae76dc1cf115bc5de6543e85d/pyeudiw/satosa/default/openid4vp_backend.py#L313

The parsing and validation of Authorization Error Response include implementation changes to step 3. and step 4.
In particular:
i. in step 3. the authorization error response must be validated and accepted (this is done by PR #376). According to the [italian specs](https://italia.github.io/eudi-wallet-it-docs/versione-corrente/en/relying-party-solution.html#redirect-uri), successful validation of the authorization error response does _not_ change this endpoint response: it is still a 200 OK + redirect url for the same device, or a 200 OK in the cross device flow, with the expectation that the /status endpoint will finally receive a 200 OK + redirect_url response.
ii. step 4 currently assumes that if we reach the redirect url, then the authentication is successful and we can go (in which case we go on passing relevant information to the satosa frontend module). In case of authentication error response this assumption is no longer true: this endpoint is intended to be reached even is no digital credential is obtained. In the "happy" case, the digital credential are fetched in this line of code
https://github.com/italia/eudi-wallet-it-python/blob/0bb0d986b3daf55ae76dc1cf115bc5de6543e85d/pyeudiw/satosa/default/openid4vp_backend.py#L352
In the authorization error response we don't have digital credential, and instead of going on with the flow at the satosa frontend, we should stop the authentication flow and respond directly signaling that the authentication process failed. In particular, the italian specs suggests as possible responses 401 or 403 based on the table in [this section](https://italia.github.io/eudi-wallet-it-docs/versione-corrente/en/relying-party-solution.html#device-flow-status-checks-and-security)¹
Note that PR #376 correctly stores the authorization error response in the session storage (in mongo). This is necessary as the authorization error response might contain information that is required for the elaboration of a meaningful response in step 4.

¹ IMO there is some ambiguity here in the italian specs and that probably deserves an issue in the docs. The ambiguity is that (1) the suggested user experience might be IMO bad, and (2) the section is basically exclusive for the cross device flow, leaving the same flow partially undefined at step 4.