feat: Add commandline interface that manages credential_configurations

[berkes]

It manages these on the oidc4vci service.
Implemented with ssi-agent details.

Adds a command and subcommand structure to allow for more cli actions.

[berkes]

@ThomasKalverda zoals beloofd, een PR die een nieuwe feature introduceert op de issuer.

Context

De oid4vci agent (unime core, aka ssi-agent, de service van impierce) vereist dat we zgn credential-configurations aanmaken. Deze zijn onderdeel van de "openid credential issuer metadata", http://issuer.example.com/.well-known/openid-credential-issuer . In de OIDC4VCI (uitgeven van credentials aan wallets) en in de OIDC4VP flow (verifien van credentials). Zo gebruikt de wallet deze bijv om te achterhalen welke encryptie algs en methods mogelijk zijn. En gebruikt de wallet het om een credential weer te geven.
En gebruikt een verifier deze om bijv te achterhalen welke attributen (claims) er zijn en wat ze betekenen enzovoort.

Implementatie details

Unime heeft een nogal gare CRUD interface hiervoor: alleen maar Create. Read, List doe ik dan via het uitlezen van die well-known. Delete bestaat niet. En Update werkt door een item met een al bestaand id te "createn" - dat overschrijft de oude.

Ik weet nog niet of ik heel blij ben met de keten (spagetti) aan dataclasses. Ik wil het enerzijds netjes afgebakend houden, maar anderzijds niet teveel duplicatie. Ik heb het gevoel dat ik nu iets teveel duplicatie heb. Als voorbeeld: CredentialConfigurationInput representeert de CrentialConfiguration zoals deze aan een cli commando doorgegeven wordt. Maar is vrijwel gelijk aan het interne CredentiaConfiguration en die is weer vrijwel gelijk aan CredentialConfigurationOutput. En die zijn allemaal weer bijna gelijk aan de hele structuur in tests/e2e/support/credential_issuer_metadata.py
Allemaal hebben ze een iets andere functie en eigenlijk niets of weinig met elkaar van doen. De duplicatie is dus eigenlijk meer "accidental duplication". Maar het voegt nogal wat mental-load en complexiteit toe die weinig praktisch nut heeft. Ik ken alleen Python niet goed genoeg om de gebruikelijke structuren en architecturen voor dit soort problemen goed te begrijpen. Dus zomaar alles ineenschuiven klopt ook weer niet.

Voor jou relevant - denk ik

• structuur van tests
• structuur van ports/adapters/services/modules - dit is hoe de hele ec-issuer is opgebouwd in essentie.
• gegoochel met dataclass en msgspec - typed json serde. Ook hoe het overal gedaan wordt in dit project.

Verbeterpunten

• Zie comment over spagetti- van dataclasses hierboven.
• msgspec "validatie" is heel goed, de foutmeldingen niet. msgspec met dataclass valideert, runtime, of wat een gebruiker aan json input geeft, wel klopt. Maar komt dan met cryptische fouten als "Expected array | null, got str- at$.credential_signing_alg_values_supported` ", niet heel lekker.
• ports-adapters werken, maar de naamgeving zit me nog niet lekker. Kan simpeler. Weet alleen nog niet hoe

[berkes]

In deze PR fix ik een error die zorgt dat op main uv niet meer kan draaien. Dat betekent dat daar ook de CI faalt. Alleen dat deel uit deze PR halen, is wat veel werk.

Om die reden merge ik deze PR. Maar feedback, opmerkingen, vragen, verbeterpunten: nog altijd heel graag. Dan implementeer ik die achteraf alsnog.