Storing calculations from expressions in the data model

### Description

Early on in the expression language project, it was assumed that expressions would take over from `RuleHandler` in every way in the future, such that jS-based rules could be deprecated and removed at some point. We're getting closer, but there's one big missing part - doing calculations and storing those in the data model.

Right now there's two main ways to perform calculations:
- Writing a rule in `RuleHandler`. This will run in app-frontend and can take leaf values, leaf values from repeating groups, and leaf values from nested repeating groups. The output can be stored as a _single_ leaf value.
- Making changes to the data model in `ProcessDataWrite` on the backend. This is much more flexible, but also binds the frontend tightly to the backend and the data processor there (as an effect, many apps need to save data frequently in order for dynamic effects in the app to occur at all - and consequently a failed save operation cannot be handled gracefully).

Doing this with expressions would introduce a third, and one with benefits over the other two:
- Calculations can be performed on both the frontend _and_ the backend (the latter is important for API users).
- Calculations can be done faster on the frontend (i.e. it doesn't have to wait for the backend to process the saving operation), and we can get closer to a frontend that works offline (at least in a shorter duration in cases where the user has a spotty internet connection, or the app itself is offline for a period of time).

Storing calculation results must not be confused with:
- Just calculating something and showing it to the user (without ever storing it). This can already be done using expressions and the `Text`, `Number` and `Date` components.

During a meeting with SSB today, we discussed this slightly, and talked about a few different solutions:

1. Making a component that takes an expression and stores it in a dataModelBinding. This was mostly inspired by a somewhat bad example I made in #1178

```json
{
"id": "myInput",
"type": "Input",
"readOnly": true,
"value": ["sum", 1, 3, 3, ["component", "someNumber"]]
}
```

It could be argued that slapping on a `dataModelBindings` in addition to the existing config would make sure this expression value was stored _and_ shown. However, it gets muddy when setting `readOnly: false`. What happens when the user types into the `Input` at that point is unclear.

2. As with expression-based validation, create a new configuration file that allows you to have a list of paths in the data model along with expressions that will set data in those paths.

### Related issue(s)

- #1937
- #1178
- #1179

No implementation files, tests, or entry points are named. Read the existing RuleHandler and ProcessDataWrite approaches, then review expression-based validation and related issues #1937, #1178, and #1179. The work is done when a decided design supports evaluating expressions and storing their results in the data model on both frontend and backend.

Written by the indexing model from the issue text.