Add lakehouse options for create table statements

[Tmonster]

Fixes https://github.com/duckdblabs/duckdb-internal/issues/6589
Fixes https://github.com/duckdblabs/duckdb-internal/issues/6590

Feature

This PR is to introduce lakehouse syntax to the DuckDB create table statement. Specifically for Iceberg, it would be nice to include the ability to set table properties, data location, partitioned by and sorted by in the create table statement.

Engines do this in different ways, but I find the SPARK/Athena way cleanest for the following reasons.

• Location, Partitioned by, and sorted by affect how & where data should be stored. These properties are also used when other engines optimize reading table data. Partitioned by and sorted by create partitioning/sort schemas in the metadata.json. These are preserved as a table updates and changes. The location is not preserved, but it is an integral part of defining an iceberg table for certain catalogs.
• Table properties are a key-value list of any properties a user wants to add, and they are not always respected by every engine.

Another option was to support a WITH () clause an shove all of these new properties in there. I feel like this will lead to confusion as iceberg & ducklake grow and change, and we will eventually move certain key/value pairs out to be more prominent in the create table statement.

If any of these table properties are declared when creating a DuckDB table, an error is thrown.

Examples in other engines
Athena

CREATE TABLE
  [db_name.]table_name (col_name data_type [COMMENT col_comment] [, ...] )
  [PARTITIONED BY (col_name | transform, ... )]
  [SORTED BY (col_name | transform, ... )] -- not in the example but is technically possible
  LOCATION 's3://amzn-s3-demo-bucket/your-folder/'
  TBLPROPERTIES ( 'table_type' ='ICEBERG' [, property_name=property_value] )

Spark

CREATE TABLE prod.db.sample (
    id bigint,
    data string,
    category string,
    ts timestamp)
USING iceberg
PARTITIONED BY (bucket(16, id), days(ts), category);

Flink

CREATE TABLE `hive_catalog`.`default`.`sample` (
    id BIGINT COMMENT 'unique id',
    data STRING NOT NULL
) 
PARTITIONED BY (data) 
WITH ('format-version'='2'); -- table properties

Trino

CREATE TABLE example_table (
    c1 INTEGER,
    c2 DATE,
    c3 DOUBLE
)
WITH ( 
    format = 'PARQUET', -- this is a table property
    partitioning = ARRAY['c1', 'c2'], -- partitioning
    sorted_by = ARRAY['c3'], -- sorting
    location = 's3://my-bucket/a/path/' -- location
);

Snowflake

CREATE [ OR REPLACE ] ICEBERG TABLE [ IF NOT EXISTS ] <table_name>
  [ EXTERNAL_VOLUME = '<external_volume_name>' ]
  [ CATALOG = '<catalog_integration_name>' ]
  CATALOG_TABLE_NAME = '<rest_catalog_table_name>'
  [ CATALOG_NAMESPACE = '<catalog_namespace>' ]
  [ PARTITION BY ( partitionExpression [ , partitionExpression , ... ] ) ]
...
  [ STORAGE_SERIALIZATION_POLICY = { COMPATIBLE | OPTIMIZED } ]

TODO:

I have a PR for Alter Table as well, I did not want to add too much all at once.

Eventually I want to add this to the Create table as, but I haven't quite found a sql statement that flows when doing this. Some examples

option 1 AS SELECT comes after table name (this means you need to know you columns before writing as select)

CREATE TABLE my_datalake.default.tbl1
PARTITIONED BY (part)
SORTED BY (id)
TBLPROPERTIES ('key'='value')
AS SELECT ...

option 2 PARTITIONED BY comes after the select clause, which will most likely lead to confusion regarding when does the select statement end, and when do the iceberg definitions start?

CREATE TABLE my_datalake.default.tbl1
AS SELECT ...
PARTITIONED BY (part)
SORTED BY (id)
TBLPROPERTIES ('key'='value')

option 3 add a SET to the create table & create table as statements.
For create table

CREATE TABLE my_datalake.default.tbl1
SET 
PARTITIONED BY (part)
SORTED BY (id)
LOCATION 's3://path1/path2'
TBLPROPERTIES ('key'='value')

For Create table As

CREATE TABLE my_datalake.default.tbl1
AS SELECT ...
SET 
PARTITIONED BY (part)
SORTED BY (id)
LOCATION 's3://path1/path2'
TBLPROPERTIES ('key'='value')

This may be the nicest as it follows cleanly from the alter table statement. It also keeps lakehouse options more recognizable. However, it will deviate from most other syntaxes