Etablere API for opprettelse / endring / sletting av dialoger/aktivitetshistorikk

### Tasks
- [x] Implementere POST-endepunkt for opprettelse av dialog
- [x] Implementere PUT-endepunkt for endring av dialog
- [x] Implementere DELETE-endepunkt for sletting av dialog
- [x] Implementere validering av forespørsel om opprettelse
- [x] Implementere validering av forespørsel om endring
- [x] Håndtere oppdateringer på dialoger som har datoer i fortid (og dermed vil treffe "er i fremtid"-valideringsregler)

Vi legger opp til at alle opprettelse/oppdateringer som gjøres på "barne-entiteter" (pt. er det ikke definert noen) skal håndteres på samme måte som PUT på aggregatet, slik at vi kan ha én Update-kommando i applikasjonslaget.

Valideringsregler

Nullable felter i ER-diagrammet er valgfrie
CreatedAt/UpdatedAt/DeletedAt skal ikke kunne oppgis i POST/PUT men utledes av Dialogporten. Unntaket er CreatedAt på DialogActivity.
Id er valgfri, og det skal genereres en monotisk UUIDv7 hvis ikke oppgitt. Hvis oppgitt skal den være en gyldig UUID (hvilken som helst versjon)
ExpiresAt er valgfri, må være i fremtiden
DueDate må være i fremtiden, og før ExpiresAt
VisibleAt må være i fremtiden, og før DueDate og ExpiresAt (se også #110)
VisibleAt skal ikke kunne endres (fjernes fra UpdateDTO)
Body skal kunne rendres som HTML, og skal valideres til inneholde et begrenset subset:
- Tags: p, a, br, em, strong, ul, ol, li
- Ingen attributter på noen tags skal støttes, med ett unntak; href på a
- href må begynne med https://
- Org skal ikke kunne oppgis, men utledes av token (settes til dummy-verdi inntil #44 er implementert)
- Party skal starte med enten /org/ eller /person/ og inneholde hhv et organisasjonsnummer eller et f-eller d-nummer. Kun sjekk well-formed-ness (mod 11-sjekk for orgnr og f/dnr)
- ServiceResource må ha prefiks urn:altinn:resource:, og identifikatoren må matche en ressurs som finnes i ressursregisteret (se API)
- Sjekk at evt. oppgitte relatedDialogElementId enten finnes i request payload, eller finnes i databasen ved update
- Sjekk av evt. oppgitt relatedActivityId / dialogElementId i activity enten finnes i request payload, eller finnes i databasen ved update
- Sletting av dialogelementer som refereres til av actions skal nektes (restrict)
- Sletting av dialogelementer som refereres til av andre dialogelementer skal godtas; referanse settes til null
- Sletting av dialogelementer som refereres til av aktiviteter skal godtas; referanser settes til null
- activityExtendedType og dialogElementType skal være gyldige URI-er (sjekk med Uri.IsWellFormedUri(uri, UriKind.Absolute)
Hvis sunsetDate oppgis, må deprecated være true

Autorisasjon

Se #44

Akseptansekriterier

GITT en førespørsel til Dialogporten NÅR forespørselen er en POST på dialog-endepunktet SÅ skal forespørselen autoriseres og valideres jf kravene over OG createtAt settes til gjeldende tidspunkt OG lagres i databasen OG returnere 204 Created, med GUID for den opprettede dialogen som en JSON-streng i body og en Location-header til dialogen

GITT en førespørsel til Dialogporten NÅR forespørselen er en PUT på dialog-endepunktet SÅ skal forespørselen referere en dialog som allerede eksisterer OG valideres jf kravene over OG aktivitetshistorikken må være tom (denne kan ikke overskrives) OG updatedAt settes til gjeldende tidspunkt OG endringen lagres i databasen OG returnere 200 OK med Location-header til dialog

GITT en førespørsel til Dialogporten NÅR forespørselen er en PUT på dialog-endepunktet og det oppgis en If-Match header som ikke matcher ETag på dialog SÅ skal forespørselen feile med 412 Precondition Failed (se #109)

GITT en førespørsel til Dialogporten NÅR forespørselen er en DELETE på dialog-endepunktet SÅ skal forespørselen referere en dialog som allerede eksisterer OG vallideres jf kravene over OG deletedAt settes til gjeldenden tidspunkt samt deleted=true

digdir / dialogporten