Expressions: Support options from expression result

### Currently
Options/code lists currently have a few variants we support:
- A simple/static list of options
- An `optionsId` that indicates a remote list of options that needs to be fetched from the server (optionally with `mapping`)
- A complex setup with `source` that maps to a repeating group in the data model (which, weirdly, has to be configured as a component somewhere to work)

I think we could replace the last (and possibly also the first) using expressions instead. That is, we can already look up keys in the data model using expressions, and after #1179 there should also be support for lists and objects.

The current configuration for `source` means you have to indicate where the group/array is in the data model, which text resource (?!) should indicate the label (as text resources can look up from repeating groups?) and which field in the data model the value should be derived from.

Note that:
- You cannot mix static options and options from repeating groups (without prefilling and hiding the static options from the group)
- As mentioned, a Group component needs to be properly configured for this to work (that is not a requirement on the backend).
- Description and help text is not supported
- Unintuitive trickery is used to make the label translatable

Also, for the very simple case of a static list of options, you always have to provide both a value and a label.

### In the future
We should only support two ways of configuring options, either via an expression or via an `optionsId` as before. For the absolutely simplest cases (i.e. yes/no) it should be sufficient to provide a basic list (using an expression):

```json
["list", "yes", "no"]
```

The values we save in the data model will then be `yes` or `no`, but the labels are displayed via text resources (so if you have text resources for `yes` and `no` we might instead show `Ja` and `Nei` as labels).

If you want to provide your own labels, you can expand the expression:

```json
["list",
{"label": ["text", "simple.yes"], "value": "yes"},
{"label": ["text", "simple.no"], "value": "no"}
]
```

And if you want to look up from the data model, from a repeating group structure, it can be done similarly:

```json
["map",
{
"label": ["pluck", "label", ["argv", 0]],
"value": ["pluck", "value", ["argv", 0]],
},
["dataModel", "path.to.repeating.group"]
]
```

This would assume the suggested `map` function in #1179 is implemented, and supports mapping directly to an object propotype in addition to functions/closures.

To make this example as clear as possible, say we have this repeating group in dot-notation:

```
path.to.repeating.group[0].label = "Foo"
path.to.repeating.group[0].value = 1234
path.to.repeating.group[1].label = "Bar"
path.to.repeating.group[1].value = 4321
```

The resulting options would map to:

```json
[
{"label": "Foo", "value": 1234},
{"label": "Bar", "value": 4321},
]
```

### Combining `optionsId` with expressions
We should also support fetching a remote list of options, and using expressions to filter/change it before presenting it as options. This could be done by adding a function to fetch options based on an id, and return the options as a list of label/value objects which could then be filtered.

### Related issue(s)
- #1179
- #936

Start by reading the existing options/source configuration and the expression and data-model work described in issues #1179 and #936. Define how expression results and optionsId results become label/value options, including static lists, repeating groups, translations, descriptions, and filtering. Done means the legacy source setup is no longer required and all listed option forms work consistently.

Written by the indexing model from the issue text.