Tables: Various fixes to table end cells in combination with insert and deletion handler

[alexanderpann]

@arimer to test the changes, please have a brief look at the MPS-Extensions Tables Sandbox to check for broken stuff. I didn't add any delete or insert handlers there.

For proper testing, you can open https://github.com/IETS3/iets3.opensource/tree/bugfix/tables as a second project and check instances of the following concepts: DataTable, Sheet, LookupTable, DecTab.

When the default implementation for deletion is used (not derived from a header deletion handler), there is a differentiation between BACKSPACE (delete to the left of cursor) and DELETE (delete to the right of the cursor). For the derived delete actions we could create a followup ticket. For INSERT (enter) and INSERT_BEFORE (Shift + Enter) the same applies. For all actions this means that depending on the ACTION it modifies the row before the current row, the current row or the next row. The left and right cell therefore modify different rows. Example:
DELETE on a left end cell deletes the current row since it is to the right of the cell, DELETE on a right end cell deletes the next row.

I didn't open a PR in IETS3 yet because without this PR the other PR doesn't build. I also added a few helper methods such as Grid#setEndCellAction that are unused in both repos as the moment but could be useful for other people.

• fixes RowEndCell: Is not generated for tables that use a Table.rowHeaders #953
• fixes EndRowCells: Delete Action always deletes the whole table #955 in combination with https://github.com/IETS3/iets3.opensource/tree/bugfix/tables
• fixes HeaderGridFactory does not (always) take HeaderReference into account #958

[arimer]

Awesome refactoring 👍🏼
Just some minor findings we should address before merging:

1. lets surround the whole logic inside the for loop with that header!=null check
2. Inside the ActionSettingAdapter, this action is not matching properly the case condition. I guess it should be a setDeleteAction()
3. We are under rightEnabled. How about we rename this variableto something "right"
4. This HeaderReference key might be not stable enought. Should we change the getFallBackText()to also take the value into account?

[arimer]

The usecases in iest3 tables work as epected 💯

However I gave up on understanding why a lookup table looks the way it looks like:

I don't know why there is the 2 literal at all and why the end-cell is not show there, but this should not hinder us in merging.

[alexanderpann]

How about we rename this variableto something "right"

We still query the left create handler, so the name is fine.

hould we change the getFallBackText()to also take the value into account?

I changed SNodeHeaderReference#getFallBackText to match StringHeaderReference#getFallBackText.

I don't know why there is the 2 literal at all and why the end-cell is not show there, but this should not hinder us in merging.

Agree but you can't insert a row here anyway, so it is correct.

[arimer]

Thanks for the cleanup 👍🏼

Changes look fine now.