=== why? ===

For the repeater (and other context-sensitive rendering), we will need
to access and mutate view data through `res.locals`. This means that all
our data needs to be available there. So, instead of passing in data to
`res.render(...)`, we consistently use a middleware that loads data into
`res.locals`. This results in easier-to-follow code, and it is clearer
that the choice of what data to load comes from the schema. For locals
that don't appear in the schema, implementers can use
`loadKeys(...keys)` or `loadFullSession` to get data from the session,
or implement a custom middleware that adds data to `res.locals`.

For the vast majority of cases, rendering should be done with the
middleware `route.render()`.

`enterContext` and `exitContext` allow us to dynamically traverse nested
data in the session. Using these, we can change the "context" from which
we get data and errors, and automatically generate `name` attributes
appropriate for the nested data.

this way, the data, error, and name will all be relative to the context.

this uses `enterContext` and `exitContext` to iterate over the existing
data and render the contents statically multiple times on the backend.
the frontend will then manage the buttons and re-ordering, in such a way
that the data will be posted properly to the server.

we will want something similar to this, but the current implementation
is not workable.

and have it automatically loaded if the file exists

bad imports should be caught immediately in testing anyways