Switch to infinite scrolling

Contributes to #941

Subsequent to https://github.com/nextcloud/tables/issues/1508

With the infinite scrolling approach we like to dissolve the traditional pagination display and controls.

We want to show up to 300 rows at the same time, with initially 100. When scrolling down, already cached rows will be blended in, while the next results are being loaded in the background. If the more than 300 elements would be visible, the top elements in the DOM will be removed again.

Therefore we have to have similar – reversed – logic for scrolling up.

We should limit the number of rows that are being kept in runtime cache to avoid consuming too much ram in the browser. Unfortunately it is not known how much RAM is available. A hard set of numbers of rows is not ideal, as rows can have very different payloads and differ in size. Thus a dynamic approach is preferable with setting a limit of 250MB (currently, a tab with 10k rows loaded consumes 1GB for me). Ideally testing with a mobile browser on an average phone should be taken into account.

On partially loaded tables, setting a filter or a sort order would need to fetch the rows from the server and re-initialize the state. A load animation - which we have when switching tables/views – should reflect this.

Start by reading the linked issues #941 and #1508, then inspect the current table pagination, loading, filtering, sorting, and row-cache behavior. Define how rows load in both scroll directions, how the 300-row window and 250MB cache limit are enforced, and how filtering or sorting reinitializes partially loaded tables. Done means pagination is replaced by responsive infinite scrolling with loading feedback and bounded memory use.