Refactor and nested types support for Parquet Reader

[hannes]

This PR refactors and extends the Parquet reader. A major feature addition is the support for nested types in Parquet files, which are mapped to DuckDB's STRUCT and LIST types. Under the hood the Parquet reader now does zero-copy of strings, which should increase performance. While I was at it, I also added DATE support to Parquet, should improve the TPCH timings ^^

[hannes]

Performance went down ~10% so need to investigate what's going on there.

[hannes]

CC @oerling

[hannes]

@apkwan @dforsber this changes quite a lot in the parquet reader, perhaps you can try the latest master before we release.

[rprovodenko]

It seems that there is a bug: after all data has been Fetched, the parquet reader returns nullptr instead of an empty DataChunk

[hannes]

It seems that there is a bug: after all data has been Fetched, the parquet reader returns nullptr instead of an empty DataChunk

Could you please post a full example of what goes wrong in a new issue? Not sure I understand.

[rprovodenko]

It seems that there is a bug: after all data has been Fetched, the parquet reader returns nullptr instead of an empty DataChunk

Could you please post a full example of what goes wrong in a new issue? Not sure I understand.

Ah, actually, disregard that, it seems that the behaviour of duckdb has changed
in query-result:
Used to be:

	//! Fetches a DataChunk from the query result. Returns an empty chunk if the result is empty, or nullptr on failure.
	virtual unique_ptr<DataChunk> Fetch() = 0;

Now:

	//! Fetches a DataChunk of normalized (flat) vectors from the query result.
	//! Returns nullptr if there are no more results to fetch.
	DUCKDB_API virtual unique_ptr<DataChunk> Fetch();

So, it used to return an empty chunk, now it returns a nullptr.