Feat/parameterized sql queries

[timsaucer]

Which issue does this PR close?

Closes #513

Rationale for this change

Users would like to use DataFrames as a parameter inside an SQL query. With this change, you can do the following:

from datafusion import SessionContext
ctx = SessionContext()
df_customer = ctx.read_parquet("examples/tpch/data/customer.parquet")
ctx.sql("select c_custkey, c_name from {df}", df=df_customer)

The string {df} in the query will be replaced with the SQL equivalent of the logical plan of the DataFrame.

What changes are included in this PR?

All of the read_parquet, read_avro, read_json, and read_csv have been changed to call register_ with a generated table name. This table name is the file name. If a table already exists with that file name, a generated UUID is used instead.

One unit test is included.

Are there any user-facing changes?

There is an addition of an optional table name to each of the read_ functions above, but it is a non breaking change for the users.

[MrPowers]

This user interface looks nice 😎

[matko]

I see that whenever a file is queried now, it'll also be registered as a table. This does have some impact, as it means these tables are now also returned whenever a context is queried for all registered tables. Meaning any sort of visualization or automation based on that would behave differently depending on whether certain queries were run.

I personally find this very surprising. I would not expect read_parquet to secretly register_parquet as that is not what this library did before, nor is it what the rust library does.

Are you sure this is fine and won't affect people? At the very least, shouldn't there be a way to filter these out easily, to cleanly differentiate between auto-registered and explicitly registered tables?

I very much see the value of the parameterized sql feature, but this seems like a very crude way of doing it.

[matko]

It is not clear to me how this relates to the rest of the change.

[matko]

There are some annoying unintended side effects to this approach. Imagine the following query

SELECT * FROM {alias} WHERE val="a string that happens to contain {alias} in it"

Since this code just replaces all occurences of {alias} with an sql query it'll do so in the WHERE part as well.
As far as I can tell, there would be no way to escape {alias} in such a way that the replacement does not occur.

This is obviously a contrived example, and it might be that this is acceptable.