refactor: Move Memtable to catalog

[logan-keede]

Which issue does this PR close?

• Part of [Epic] Split datasources out from datafusion crate (datafusion/core) #14444

Rationale for this change

now that catalog is dependent on datasource, MemTable can go to catalog.

What changes are included in this PR?

move In-Memory Table Provider to catalog.
and statistics to datasource.

Are these changes tested?

By Github CI.

Are there any user-facing changes?

you can access datafusion::datasource::memory::{DataSourceExec, MemorySourceConfig, Tableproviders.., CatalogProviders.., SchemaProviders..},
Reason:

1. Backward Compatibility DataSourceExec, MemorySourceConfig, MemTable.
2. it is intuitive to access Tableproviders.., CatalogProviders.., SchemaProviders.. together

[jayzhan211]

I think MemSink should be in datasource crate

[logan-keede]

Unless you would specifically like to make it public (which is also reasonable).
I think it is fine to have it in catalog because MemSink is a private struct used only by MemTable even though it logically makes more sense to have it with its DataSource implementation to like other DataSink impls.

I have pushed a commit feel free to drop it

[berkaysynnada]

I agree with Jay. We shouldn't try to push every piece of code to the higher level crates, as maintaining integrity and logical structure is more important to keep each crate meaningful.

[alamb]

Maybe as a follow on PR we can make a new crate catalog-memory to hold the in memory catalog implementations from the catalog traits.

Something I noticed recently while building datafusion is that compiling the catalog crate itself takes non trivial time too (7s on my laptop as I recall)

I left more notes here: #13814 (comment)