feat: federate expression subqueries

[sardination]

Closes #31

Recursively optimize subqueries in expressions as well.

[backkem]

Hi @sardination, thank you for having a look at this.

optimize_recursively recursively walks over the plan and tries to find the largest possible sub-plans that can be federated by one remote. The PR as it stands now, adds the subqueries to the recursion but, as your TODO comment mentions, it doesn't incorporate it in the logic to determine the largest possible sub-plans yet.

To make this work, I was thinking in the direction of building a custom stack to hold the inputs at a specific plan depth, similar to ExprIdentifierVisitor. That way the entire function can be re-written as a TreeNodeVisitor (which exists for expressions while the .inputs() method doesn't). I need to find more time to complete this though.
Update: Seems like a dead-end for now. Thinking up something else..

[backkem]

I noticed the ScalarSubquerys aren't supported by the physical planner. They are replaced in the scalar_subquery_to_join optimiser. I guess this means we need to re-write the analyzer to an optimizer and schedule it after the scalar_subquery_to_join one.

[backkem]

Continued in #37.

[philippemnoel]

Thank you for picking this up @backkem!