Preserve pagination after actions which trigger a grid update

[wetneb]

This is a backport of #5411 to the master branch. Closes #33, closes #570, closes #572 (already marked as such by #5411).

For this one, although the change was sort of forced on me by the new architecture, it can be backported with reasonable effort to the master branch.

Summary: this changes the grid pagination so that users to not input a page number, but the index of the first row in the view. Why do this?

• it solves Manually selecting a reconciliation match returns the grid to page 1. #33 and others, because starting row number can be meaningfully preserved for all row-wise operations. In comparison, preserving the page number is not guaranteed to keep the view in the same place because changes to earlier rows can shift page boundaries
• it's generally a better practice for pagination, as is explained by various documents (such as https://medium.com/swlh/sql-pagination-you-are-probably-doing-it-wrong-d0f2719cc166)
• it's required for the new architecture, which is what pushed me to working on this.

It's a change that has implications for the UI and the web API (which is not meant to be stable).
It relies on manually annotating all operations with row/record preservation. In this PR it is done in the frontend, but further backend changes will move this information to the backend (making it possible to detect the row/record preservation of sequences of operations run via the apply-operations command, for instance).

One oddity of this change is that in records mode, the pagination is still done based on row ids and not on record ids. This is intentional, because:

• it would make it possible to switch between rows and records mode while preserving pagination (although this is not enabled so far)
• so far, the new architecture drops the notion of record ids and uses the starting row index instead. This is primarily for performance reasons, as it enables more efficient record grouping.