WIP: LogicalPlan::TableScan now refers to table provider by name

[andygrove]

Which issue does this PR close?

Closes #2247.

Note that this is an early WIP and not functional yet.

I am putting up this PR in an early state to get feedback on the general approach.

Rationale for this change

The logical plan currently depends on the physical plan, which prevents us from moving the logical plan into its own crate alongside the logical expressions (which is needed in order to support subqueries, and also to better support the use case where DataFusion is being used just for SQL query planning and then using a different execution engine).

The reason that the logical plan depends on the physical plan is that LogicalPlan::TableScan has a reference to a TableProvider which has a scan method that returns ExecutionPlan.

What changes are included in this PR?

• TableScan struct no longer has a direct reference to a TableProvider instance. The TableProvider is looked up when needed, based on table_name.
• CatalogList is now passed to optimizer rules, allowing tables to be resolved during optimization
• TableScan now contains full_filters, partial_filters and unsupported_filters so that we can still show them in fmt::Display without having access to the TableProvider
• Fix Ballista serde
• Update many tests to provide a valid CatalogList

Are there any user-facing changes?

Yes, this is an API change.

[matthewmturner]

@andygrove would you be able to provide color on the use case for passing CatalogList to optimizer rules / resolving tables during optimization?

[andygrove]

This was too ambitious. Replace with simpler solution in #2284