I/6122: Handling spanned table cells in pasting scenarios

[jodator]

Suggested merge commit message (convention)

Internal (table): Handle spanned table cells in pasting scenarios. Closes #6122.

Fix (table): Setting column as header will now split it col-spaned cells. Closes #6658.

---

Additional information

This PR:

• Introduces handling cases of spanned cells (both in selected table and pasted table) that have spans that exceeds rectangular selection.
• Introduces fix to Setting column as header should split it col-spaned cells #6658 as the utils used were also created (they mirrors the logic of setting table header rows).
• Handles a rectangular selection with cells spanned at the last row or column (like here: 6120: Pasting table into table - base scenarios. #6786 (comment))
• We also assume that pasted table is either valid or near valid. One case of invalid table structure was moved to a followup.

[FilipTokarski]

Not 100% sure if this is valid for this PR ( or rather I didn't catch it in the previous one ), but I'll share this here:

• Case 1
  

• Case 2
  

In my view ( based on how pasting this selection works in most other cases ), the expected behaviour should be something like this:

[niegowski]

We have multiple different naming conventions for startRow/endRow vs firstRow/lastRow. I think we should stick to one notation.

[jodator]

That's a good point. Unfortunately we have both in some API points and I'm not sure which one is better.

[niegowski]

In my last commit I addressed most issues. 

Still to discuss:

• Naming convention for startRow/endRow vs firstRow/lastRow
• Real dimensions of pasted table
• We still need to extract some of the logic to functions.

Also I didn't reviewed tests.

[FilipTokarski]

Please refer to my next comment 👇

If there are vertically and horizontally merged cells and they intersect each other on paste:
- first pasting case removes color from orange cell and splits it into 6 cells
- second case creates new column and moves 6th cell there

[niegowski]

If there are vertically and horizontally merged cells and they intersect each other on paste:

• first pasting case removes color from orange cell and splits it into 6 cells
• second case creates new column and moves 6th cell there

Did you checked it after latest fixes?

[FilipTokarski]

Sorry, my bad 🤦 Splitting rows works fine now. Only the color issue still exists in some cases:

[jodator]

Did you checked it after latest fixes?

Please - if you fix something - add tests. I'm debugging what's happening as there was no new tests and I'm thinking why this is working now.

Test are needed for changed logic and bug fixes. I'll add those test.

[FilipTokarski]

Steps to reproduce:

1. Create a 2x2 table and some another bigger table
2. Select all cells in 2x2 table and merge them into one
3. Now there are two scenarios:
   • A ) select small table by holding shift and clicking the cell, copy and paste into bigger table
   • B ) select small table as a whole, copy and paste into bigger table

In scenario A pasted content is a single cell, whereas in B it remembers that initial table width was 2 columns. Not sure if this is incorrect, but it's a bit counterintuitive, because what you see when copying in both cases, is only a one-cell-table:

[jodator]

Sorry, my bad facepalm Splitting rows works fine now. Only the color issue still exists in some cases:

Moved here: #7246.

[jodator]

Select all cells in 2x2 table and merge them into one

The bug is here :) Already reported: #6609. Would be nice to fix it eventually.