Mulig feil i datoformat, da dette er avhengig av system-locale

### Description of the bug

Jeg kjørte en automatisk test i `app-frontend-react` på min linux-maskin i dag (23. november 2023), og vår strenge regex snappet opp at datoformatet ikke var helt som forventet:


Når jeg gravde i koden, ser det ut til at dagens dato settes av dette prosjektet, og sendes til APIet til SSB vha. [DateOnly.ToString()](https://learn.microsoft.com/en-us/dotnet/api/system.dateonly.tostring?view=net-8.0#system-dateonly-tostring). Den funksjonen vil gi forskjellige datoformater basert på gjeldende locale (eller 'culture' som Microsoft kaller det), men jeg vet ikke om vi kan være 100% sikre på hvilket format SSB forventer.

Når jeg prøver å sende inn forskjellige datoer som parameter, får jeg forsåvidt forventet oppførsel, så ting går generelt bra:

https://github.com/Altinn/codelists-lib-dotnet/assets/700139/dcd0d5e3-b076-420f-a6a0-21e4bbdbda8d

Jeg mener at formatet her blir parset av dotnet og man kjører ToString() uavhengig av om jeg sendt inn en annen dato eller ikke, men med dobbel parsing av dato av ukjent/varierende format (både her og angivelig hos SSB) mistenker jeg at det er lett å tråkke i salaten og ende opp med en dato som feilaktig blir tolket på amerikansk format (MM.DD.YYYY) istedenfor norsk format (DD.MM.YYYY). Ikke den største krisen kanskje, men dette ser jeg fort kan føre til at en liste over kommuner (eller en annen kodeliste) en gang i fremtiden kan gi feil resultat i en kort periode i starten av hver måned (når datoene kan tolkes på amerikansk format). Med andre, en slik feil som er notorisk vanskelig å finne rotårsaken til.

Det kan nok med andre ord være lurt å bruke både parsing og printing av datoer som har et fast format uavhengig av plattform/locale/culture.

### Steps To Reproduce

Prøv ulike operativsystemer eller locales på maskinen

### Additional Information

_No response_