What is broken?

The current algorithm which calculates the first and last visible rows does not take into account content wrapping (and has a number of other problematic edge cases). This causes the table to overflow its height when text wraps:

--------------------------------------------
| One        | Two          | Three        |
--------------------------------------------
| This works | just fine    |              |
--------------------------------------------
| This row   |              |              |
| instead is |              |              |
| counted as |              |              |
| if it was  |              |              |
| 1 cell     |              |              |
| high       |              |              |
--------------------------------------------

In this example, if the table height was set anywhere between 7 and 11, the algorithm would think the second row fits and result in a table 12 cells high.

This is partially due to expandRowHeights not actually updating the rowHeights field on resizer (which means the algorithm does not have access to the row heights that have been calculated based on wrapping the contents), but also due to a simplified implementation which does not really try to take them into account.

What am I changing?

Rewrite the visible rows calculation to take content wrapping into account, making sure we consider the actual row height that will be used when rendering the table.

This has the following consequences:

• Rows will not be included in the visible range if they won't fit after wrapping based on the calculated column widths.
• To avoid being able to scroll past the end of the table, the algorithm will also adjust the first visible row if necessary to fill the available height once the yOffset allows the last row to be visible.

Note that all previous tests still pass with the exception of a single one (TestTableShrinkWithYOffset) which actually relied on the previous yOffset behavior: the old algorithm with the given offset of 80 and a height of 45 would show rows 81-100, while the new one shows rows 80-100 because 80 actually fits in the given height.

Since we are using this in a TUI, add an AdaptiveOverflow option which forces the (potential) overflow row to occupy all of the remaining height, ensuring the table actually respects the provided height instead of treating it as a maximum when hiding certain rows. This means we can use the table in a grid-like layout without creating gaps which depend on the height of the visible rows.

• If the option is disabled, the overflow row will inherit the height of the row which would've been rendered there (as it did prior to this change)
• If the option is enabled, the overflow row (when present) will take up exactly as much space as needed for the table to match the provided height.

I added tests covering both aspects: they would fail with the previous broken implementation and they now pass, and they also test the new adaptive overflow behavior.

Sorry I've skipped creating a discussion, but I consider this to mainly be a bugfix rather than a new feature. If you feel strongly against the adaptive overflow feature or about its naming, happy to change this.

• I have read CONTRIBUTING.md.
• I have created a discussion that was approved by a maintainer (for new features).