Saving parsed query to the context

[wk8]

Sometimes it's nice to be able to access the parsed query, say in a Table's callbacks; for example, if one implements a table backed by a system that allows fast access for very specific queries, it might not be possible (or at least not easy) to take advantage of that using one of the pre-defined *Table interfaces. In that case, the most straightforward way to implement this would be to return the relevant subset of rows from PartitionRows, depending on the query.

This patch allows to access the already parsed query, instead of parsing it all over again.

Happy to add tests if you're okay with the general idea.

[max-hoffman]

This is pretty safe to merge, I do think the way you plan to use the AST might give you some issues. Normally we would fold execution time decision making into the plan layer with transformation rules. Depending on how you are using GMS, if might be possible to extend the engine's analyzer with custom rules. That would look similar to your AST walk, but on a plan sql.Node instead (we have a lot of search and pattern matching helper functions). Setting a property on your custom table at planning time generally lends itself to easier extensibility, testing, debugging, etc.