Possible rework of the drawing step

[PgBiel]

Currently, the table is drawn using a single-column grid with every row group, that is, every set of rows that is inseparable due to being rowspans (or due to being a user-defined header). Additionally, every row group's height must be known in advance. This leads to a few problems, such as a cell from the row group below overlapping with the horizontal line drawn by the row group above (as the order of horizontal line drawing has to follow the order of row groups in some way).

So, a possible way around this is to change the draw method such that we are the ones who calculate when the table has to advance to the next page. At every page, we calculate its size, and then how much is left to draw (subtract max pos (bottom+right) from table pos; on later pages, max pos from min pos (top+left)). With that information, we can calculate the height of row groups progressively, until we reach a point where the next row group would exceed the remaining page height, in which case we stop iterating, place a block(breakable: false) with the appropriate height to fit all the cells, perform the drawing process with place (fill -> lines -> cells), and then place another block which will repeat this process.

As a consequence:

• It would no longer be "hacky" to know when the page ends or starts for our table (we determine that!).
• Fractional rows would be able to size properly on each page (as we re-calculate row sizes);
• We would be able to re-implement table headers (and maybe even footers, captions etc.) without much hassle (as we are in control over page splits);
• Implementing custom borders around the table (maybe with radius) would be possible, as we are in full control of the table's display on each page;
• Cells and other table elements would no longer have possibly awkward interactions between each other.

This will, however, require a considerable refactor, so this will take time to do.

[PgBiel]

Also, this approach might enable us to use just layout to figure out page turns, which would speed things up a lot (by not depending on locate).