Limit / offset bug fixes

[zachmu]

Prior to this PR, the following query returns no rows on a table with many:

SELECT i FROM mytable LIMIT 1 OFFSET 1;

In fact, no queries combining offset and limit return correct results before this PR.

This is because the parser creates an offset node that wraps a limit node, and the limit node's counter is incremented for every row the offset node skips, so that when the offset node is done skipping rows, the wrapped limit node returns fewer rows than asked for.

The fix is to add the offset to the row count when constructing the limit node. This is much simpler than adding ResetCount() or similar, but has the disadvantage of making the plan slightly more difficult to understand to a naive reader, best illustrated by this modified test, where the limit node has a limit of 7 instead of 2 as expressed in the query:

`SELECT foo, bar FROM foo LIMIT 2 OFFSET 5;`: 
     plan.NewOffset(5,
	plan.NewLimit(7, plan.NewProject(
		[]sql.Expression{
			expression.NewUnresolvedColumn("foo"),
			expression.NewUnresolvedColumn("bar"),
		},
		plan.NewUnresolvedTable("foo", ""),
	)),
),

Also included in this PR, queries with negative limits or offsets now return an error.

[zachmu]

Sorry the commit history is so messy here, missed a -s on one of my commits and had to scramble to fix it :p

[erizocosmico]

Good catch!

[zachmu]

Thanks for the review, friends! As soon as you merge this in I have another batch of bug fixes incoming.

[erizocosmico]

I have been thinking about this and perhaps there could be a simpler solution, which would just be adding the offset node before the limit node. What do you think?

[zachmu]

Good suggestion, Miguel. Much simpler. Please review and merge at your convenience.

[ajnavarro]

Thanks a lot for the contribution!