feat: introduction of simple table functions

[benbellick]

• feat: introduces a notion of YAML-defined table functions which are represented as a new TableFunctionRel (take in no relations)

Closes #823

[benbellick]

Every other function type has a FunctionOption field around here. Do we need that for table functions as well?

message TableFunctionRel {
    ...
    repeated FunctionOption options = 4;
    ...
}

[benbellick]

Would it be better to come up with a more explicit way to mark the inability of deriving an output schema for a particular table function? Or is it sufficient to just let the absence of the schema field indicate this?

[benbellick]

Is a more appropriate name for this GeneratorTableFunctionRel as introduced by
@jacques-n here?

In my mind there are two possible paths we can go down which determine the appropriate name.

1. We could explore expanding this proto (by e.g. adding a relations input field) so that it appropriately models both kinds of table functions. In this case, keeping the name as TableFunctionRel makes sense.
2. We could introduce a brand new relation to represent table functions which take relations as input. In this case, it would make sense to rename this relation to GeneratorTableRel or some name which distinguishes it from the other kind of table function.

[benbellick]

I added this to be consistent with the other function definitions, though AFAICT, this isn't really used anywhere. I found #193 from a few years ago which suggests that this should continue to be updated, but I'm not sure if that is still the prevailing philosophy.

[benbellick]

Other functions have variadic final argument logic like:

message TableFunction {
    ...
    oneof final_variable_behavior {
      FinalArgVariadic variadic = 10;
      FinalArgNormal normal = 11;
    }
    ...
}

However, I skipped it for now for simplicity. Is it necessary on a first pass?

[benbellick]

Ideally, we would be able to model something like:

SELECT unnest(col) FROM table;

However, my understanding is that this is really syntactic sugar for:

SELECT u.value 
FROM table t 
CROSS JOIN LATERAL unnest(t.col) AS u(value);

If that is correct, then we really need LateralJoinRel to properly model this usage of unnest.

It is probably worth then clarifying somewhere in the documentation introduced in this PR that the arguments to a table function can't be field references.

[benbellick]

TODO: this could probably use a little work to make it a bit nicer. I'll work on that later once we have some general agreement on the spec changes.

The change here is for now just to get CI/CD to pass.

[benbellick]

TODO: I think this section could use a little bit of work:

• add some examples with YAML files to demonstrate the difference between derived / explicit
• Make the fact that there are these two kinds a bit clearer.