Limit fetching of rows to a certain threshold

Contributes to #941

Currently the frontend tries to load all rows from a table or view. This is currently not a problem in rendering, but can be a problem for loading times, client RAM usage, and limit of roughly 65k/3 in Postgres that we may run against in the current approach.

In #1507 we prepare a backend API that can take necessary parameters to do effective pagination, even with dynamic values provided.

In a first step we want to limit the maximum number of rows to be fetched, while keeping the current pagination system. When requesting the value, dynamic filters and sorting rules shall also be supplied with the query.

The frontend shall request to load 1101 rows (eleven complete pages, plus and indicator of 1 for more rows). If there are more data rows available, the user shall be informed by a message with the hint that filtered loading and sorting can finetune the result set.

Internally, we store the information whether this table or view is loaded fully or just partially.

Start by tracing the frontend's current pagination and the backend API prepared in #1507, including how dynamic filters and sorting are passed. Check where table or view loading state is stored and how row-count messages are rendered. Done means requests are capped at 1101 rows, partial loading is tracked, and users are informed when more rows exist.