Add invalid_tx_code error code to pre-authz code flow

[awoie]

Fixes #474

[awoie]

@c2bo @tplooker @Sakurann @jogu @paulbastian could somebody please review this.

[paulbastian]

This makes a lot of sense, please consider to strengthen the normative language.

[awoie]

@Sakurann @fkj @paulbastian @tplooker I updated the PR accordingly to:

• add security considerations to errata
• invalid_tx_code is still a should, not a must for backward compatibility. however, i tried to make 1.0 errata future-proof.
• scope of this PR is limited to transaction codes. note that pre-authz codes must be short-lived as per 1.0. This PR just talks about transaction codes where the WG was not able to provide an example where the transaction code is long-lived. also note that it is a should, not a must.

[fkj]

I was convinced during the WG meeting that the transaction code lifetime issue is "superseded" by the pre-authorized code lifetime already being "short-lived", whatever that means for the specific application. So I'm OK with just saying transaction codes SHOULD also be short-lived.

[Vanderkast]

In general, LGTM.

Assume the following scenario:

1. The End-User passes OOB process prepending OID4VCI Pre-Authorized code flow.
2. The Issuer sends the Credential Offer and the tx_code.
3. The End-User starts Credential Issuance via the Wallet.
4. The Wallet accesses Token Endpoint of the Authorization Server (AS) and exchanges tx_code for an Access Token.
5. The Wallet accesses Credential Endpoint of the Issuer but receives HTTP status code 202 involving the Wallet to access Deferred Credential Endpoint later on.

Due to one-time usage of tx_code, the Wallet cannot re-issue Access Token if it is expired.

1. Is Credential Response HTTP status code 202 considered at all in such flow?
2. If so, do we expect AS to return Refresh Token so the Wallet can refresh Access Token?