Table Functions with non-literal arguments cannot support efficient lookups.

~~The following query causes a panic in Dolt:~~

~~`select * from dolt_log() seq1 where commit_hash in (select SEQ2.commit_hash from dolt_log() SEQ2);`~~

~~The panic happens in the function `addRightSemiJoins`, where there's an attempted cast of `*dtablefunctions.LogTableFunction` to the `sql.TableNode` interface. Essentially we assume that the child of a `TableAlias` node is always a `sql.TableNode`, but in this case, `LogTableFunction` does not implement that interface. And currently, it _can't_.~~

Currently, table functions that take non-literal arguments cannot correctly implement `sql.TableNode` if they appear within a subquery. This is because the TableNode interface allows for lookups by implementing the `PartitionRows` method, which takes a `Partition` value created by either the `Partitions` or `LookupPartitions` methods. But none of those methods take a `sql.Row` parameter that describes the values in the parent scope. Consequently, the result of scans or lookups on table functions cannot change based on the table function's parameters, unless those parameters are independent of the outer scope.

It is currently possible to detect this by scanning the arguments at the time that the TableFunction node is created, recording if there are any non-literal arguments, and then checking when we would create a Partition. But I don't think we can prevent the engine from optimizing based on the assumption that this lookup can be performed.