Test ressurskoblinger på en tilgangsliste

**Testdata: én permanent ressurs, ikke en ny per kjøring.** Konklusjonen i #488 er at det ikke er bærekraftig å opprette og slette ressurser fortløpende, fordi slettingen etterlater rader i `resourceregistry.resourcesubjects` som ingenting rydder, meldt som Altinn/altinn-resource-registry#848. Denne testen skal derfor ikke opprette og slette noe per iterasjon. Den skal bruke én ressurs med hardkodet identifikator og kjent policy, som opprettes én gang og blir liggende, og som testen aldri sletter. Da blir residuet et konstant antall rader per miljø i stedet for et par nye rader hvert kvarter.

Det som må bestemmes er hvordan ressursen kommer på plass i de miljøene vi kjører i. Enten seedes den én gang utenfor testen, eller testen leser den først og oppretter den bare hvis den ikke finnes. Det siste holder testen selvstendig, men gjør at det aller første løpet i et nytt miljø skriver.

En tilgangsliste kobles til ressursene den styrer tilgangen til. Koblingene leses paginert med `GET /access-lists/{owner}/{identifier}/resource-connections`, opprettes eller oppdateres med `PUT .../resource-connections/{resourceIdentifier}` og fjernes med `DELETE` på den samme ruten. Ingen av de tre er dekket.

Clientene og byggeblokkene finnes for alle tre (`AccessListsGetResourceConnections`, `AccessListsUpsertResourceConnection`, `AccessListsDeleteResourceConnection`), og ingen av byggeblokkene importeres.

Testen bør opprette en ressurs med `accessListMode` satt slik at tilgangslister gjelder for den, opprette en tilgangsliste, koble de to sammen, lese koblingene og sjekke at ressursen er der med de handlingene koblingen ble opprettet med, fjerne koblingen og sjekke at listen er tom, og rydde opp begge veier. `ServiceResourceBuilder.withAccessListMode` finnes alt.

Åpent spørsmål: om koblingen kan peke på hvilken som helst ressurs, eller om ressursen må ha `accessListMode` satt til `Enabled` for at `PUT` skal gå gjennom. Det avgjør om testen må lage sin egen ressurs eller kan bruke en som finnes.

Scope: avklart i #482. `resource.admin` dekker både `GET`, `PUT` og `DELETE` på ressurskoblingene og går klar av eierkravet. Merk at `UpsertAccessListResourceConnection` gjør en ekstra eiersjekk i metoden, på eieren av ressursen koblingen peker på og ikke bare på eieren i ruten, og den sjekken går også gjennom for `resource.admin`. Ressursen testen kobler til må derfor eies av samme orgkode som tokenet hvis vi senere bytter til `accesslist.write`.

Del av #473

Start with the AccessListsGetResourceConnections, AccessListsUpsertResourceConnection, and AccessListsDeleteResourceConnection clients and their corresponding building blocks; none is currently imported. Read ServiceResourceBuilder.withAccessListMode and the decisions in #482 and #488, then determine how the permanent resource is provisioned. Done means the test creates or finds the resource and access list, verifies paginated connections and actions, removes the connection, confirms the list is empty, and cleans up the access list.

Written by the indexing model from the issue text.