Break up DDL and Query LogicalPlan variants

[alamb]

Is your feature request related to a problem or challenge? Please describe what you are trying to do.
As mentioned on #1266 and #1266 (review), as we add more capabilities to DataFusion like CREATE TABLE AS SELECT and DROP TABLE it seems like there are now really two types of LogicalPlan variants:

1. Those that can actually be compiled / run as a ExecutionPlan (e.g. LogicalPlan::Select)
2. Those that must effectively be "interpreted" in the DataFrame (e.g. CreateTable, DropTable, etc)

Depending on the usecase, some DataFusion users will want to support the built in DDL (CreateTable, etc) and smoe will not. For example CREATE EXTERNAL TABLE could easily be a security hole for systems that want to use Datafusion to provide a SQL read-only access to their data. I worried about such a problem in IOx recently -- see https://github.com/influxdata/influxdb_iox/pull/3051

It would be great to split up the types of plans that come out of the planner so users of DataFusion (such as IOx) could be better sure that the DDL commands are not executed (unless they want the to be).

Describe the solution you'd like

Perhaps the SQLParser could produce something like

enum ParsedPlan {
  Query(LogicalPlan),
  DDL(DDLPlan)
}

Where DDLPLan was like

enum DDLPlan {
  CreateExternalTable {...}
  CreateMemoryTable {..},
  DropTable {..}
  ...
}

**Describe alternatives you've considered**
A clear and concise description of any alternative solutions or features you've considered.

**Additional context**
Add any other context or screenshots about the feature request here.

[liukun4515]

I can take on this task. @alamb

[liukun4515]

I will do this after the refactor #1228

[alamb]

FYI @liukun4515 I have a PR with the first part of this in #6121