repeat_row -- disallow on WITH ORDINALITY; add repeat_row_non_negative

[ggevay]

This PR kicks off the repeat_row productionization work stream. Resolves SQL-160. Resolves SQL-161.

I suggest reviewing commit by commit:

1. just some renamings to match up internal names to the SQL name
2. Add repeat_row_non_negative as a new SQL function, which errors out on a negative input (instead of producing a negative number of rows). It's less powerful than repeat_row, but its advantage is that it doesn't have the restrictions and dangers that repeat_row has. The immediate motivation for this was to be able to keep using this in tests of WITH ORDINALITY when repeat_row is disallowed, but it might also be useful for users for other purposes, so users could be allowed to freely use it. (For now, it's guarded by a feature flag which defaults to off, and I haven't documented it yet, but if we think this would be indeed a useful function for users, then I can add docs and turn it on in a follow-up PR.)
3. The main point of the PR: disallows repeat_row in WITH ORDINALITY and in some other constructs that are implemented using WITH ORDINALITY. We need to make this change for productionizing repeat_row, because WITH ORDINALITY is not well-defined for negative diffs, and the implementation panics on a negative diff. (Note that this is not violating backwards compatibility requirements, because repeat_row was not officially supported so far, and has not been turned on for most users.)

Note: An alternative to disallowing repeat_row with WITH ORDINALITY would be to make WithOrdinality::eval not panic on negative diffs. However, this seems to be not easily possible without a performance hit or complicating the code: We'd need to either

• eval the table function twice, only checking the diffs at the first evaluation, costing CPU;
• save the eval result in a Vec, costing memory;
• make the flat_map closure somehow fallible, for which I don't see an easy way. (E.g., we could make the iterator's item type Result, but then would need to touch every caller of TableFunc::eval and every arm of the big match in TableFunc::eval, and might slow things down a bit. Or we could report the error in an Rc<Cell<...>>, which also feels convoluted, and potentially costing CPU.)

We could reconsider making it possible generally to return errors in the middle of table function iterators, if we ever find a need for this in some other table function. But repeat_row together with WITH ORDINALITY feels so rare, that it seems ok to just disallow this combination for now. Edit: https://github.com/MaterializeInc/database-issues/issues/11324 would be one more reason to implement error returns inside this iterator, but that issue seems also quite low priority.

[def-]

SELECT * FROM repeat_row_non_negative(9223372036854775807) WITH ORDINALITY LIMIT 1;

Returns wrong result:

 ordinality
------------
(0 rows)

Should be 1.

[ggevay]

@def-, good catch! The bug is in WITH ORDINALITY, and is also present on main with

SELECT * FROM repeat_row(9223372036854775807) WITH ORDINALITY LIMIT 1;

It's coming from inside WithOrdinality::eval, where next_ordinal + diff overflows. Unfortunately, there is no easy way to report an error from inside that iterator at the moment (as explained in the last part of the PR description). So, fixing this would need a bigger refactoring, so I'll create a separate issue for it. Edit: https://github.com/MaterializeInc/database-issues/issues/11324