Define row span behaviour for row context resolver

[voytech]

General row span behaviour rules:

1. Row span can be set on cells associated with property keyed columns. As long as property reference based column ids are reserved for row definitions originating from source collection elements - row span rules cannot be validated entirely during table build time - we must support additional operational state holding cell scoped, and row scoped offset for row resolver.
2. Row span - when defined for cell - should always take precedence - it should be always rendered first, next rows should be aware of row span present on specific column - and behave according to selected strategy.
3. Row span may affect downstream row by applying different strategies:

• PUSHBACK - shifts downstream rows by the value of remaining row span. This requires maintining row context associated index offset ( offset to be applied on initially matched (after request) row index)
• SHADOW - downstream row cell affected by upper row span value is shadowed by upstream row cell. Remaining cells in the row are rendered normally
• SKIP - all downstream row cells affected by upper cell row span value are skipped. (Entire downstream row/s colliding with considered span value is lost)
• THROW - an exception is thrown and entire export fails.

Row span build time validation:

1. Row span collision checks should occur at table definition time when defining row with index predicate literal row id. (when using dynamic predicate lambda on SourceRow - You may not be able to deremine row index at build time as it depends on dynamic context.)