Custom properties/fields in code lists

### Description

As of now, the `AppOption` class accepts four fields:
- `value`
- `label`
- `description` (optional)
- `helpText` (optional)

We should remove this restriction to allow for any amount of key/value data in this object.

### Background

When [we talked about the naming of this concept of 'code lists' / options](https://digdir.slack.com/archives/C07JV0DAU3Y/p1734097613967479?thread_ts=1734001887.002389&cid=C07JV0DAU3Y), @altinnadmin said:

> Svaralternativer etc blir fort litt begrensende i forhold til den opprinnelige tanken bak kodelister. Man kan benytte en kodeliste som svaralternativer i en skjemakontekst, men de er ikke begrenset til det, og de "er" ikke det.
> Kodelister tilbyr data med en en unik identifikator (koden) som refererer til en eller flere verdier via API. F.eks. en kodeliste med kommuner som også inneholder info om fylke slik at man enkelt kan lage f.eks. filtrering av kommuner basert på fylke, og vedlikeholde disse koblingene ett sted når kommuner slås sammen, uten behov for å hardkode disse i hver eneste app/tjeneste.

This ties into the `keyValuePairs` passed to the `IAppOptionsProvider`. It's possible to send query parameters, but if it's only for filtering which municipality you should be able to select depending on the county, simply returning all options from the API and filtering in frontend would be more effective:

```json
[
{
"value": "1103",
"label": "Stavanger",
"county": "Rogaland"
},
{
"value": "1201",
"label": "Bergen",
"county": "Vestland"
}
]
```

Now that [filtering via expressions](https://docs.altinn.studio/altinn-studio/guides/development/options/functionality/filtering/) is available, you could set this up with:

```json
{
"id": "choose-municipality",
"type": "Dropdown",
"optionId": "municipalities",
"optionFilter": ["equals", ["value", "county"], ["component", "choose-county"]]
}
```

Start by locating the AppOption class and the IAppOptionsProvider entry point, then inspect how keyValuePairs and option data are represented and serialized. Done means options can carry arbitrary custom key/value fields alongside value, label, description, and helpText, while preserving the filtering example's data flow.

Written by the indexing model from the issue text.