Move LogicalPlan enum to datafusion-expr crate

[andygrove]

Which issue does this PR close?

Closes#2245

Rationale for this change

We want to move the logical plan to the expr crate so that we can implement subquery expressions (this requires introducing new expressions that reference logical plans).

What changes are included in this PR?

• Mostly just moving code between crates
• Removed the FromStr implementation on FileType in the SQL parser and converted into parse_file_type method. This is more consistent with other parsing code and fixed a compilation issue.
• Ignored the rustdoc documentation on some methods in LogicalPlan. See follow-on issue for more details.

Follow-on issues

• Update LogicalPlan rustdoc code to not use LogicalPlanBuilder #2308

Are there any user-facing changes?

Yes - code has moved around so this is an API change. I did try to minimize the impact by re-exporting types from their previous location.

[andygrove]

AMD64 test failure seems unrelated. Maybe an unreliable test?

thread 'sql::explain_analyze::explain_analyze_baseline_metrics' panicked at 'plan: GlobalLimitExec: limit=3, metrics=[output_rows=1, elapsed_compute=NOT RECORDED, spill_count=0, spilled_bytes=0, mem_used=0]
', datafusion/core/tests/sql/explain_analyze.rs:145:13
failures:
sql::explain_analyze::explain_analyze_baseline_metrics
```

[alamb]

I wonder if making this a separate crate like datafusion-logical-plan might be considered? Is there any reason the logical plan structs need to be in the expr? I could (potentially) see a use of just Exprs without also LogicalPlan

[andygrove]

I was working towards having the logical plan and logical expressions in the same create (currently named datafusion-expr but potentially could be renamed to datafusion-logical-plan).

The main motivation is that I was planning on adding something like:

pubenumExpr{Exists{subquery:Arc<LogicalPlan>,negated:bool}
...
}

This would be similar to Apache Spark:

caseclassSubquery(child: LogicalPlan, correlated: Boolean) extendsOrderPreservingUnaryNode {

Also similar to Calcite:

publicclassRexSubQueryextendsRexCall {
publicfinalRelNoderel;

I'm not sure how else we would model this but am open to suggestions.

[andygrove]

@jackwener@xudong963@mingmwang@paveltiunov fyi ☝️ this is related to conversations you have all been involved in previously so would like to get your feedback on this PR if possible

[alamb]

YOLO! Let's do this