This PR adds a new `LogicalType::TUPLE` which replaces the previous
"unnamed" special case of struct-types with a dedicated type.

### Syntax Changes

- `{}` now returns a valid empty `STRUCT` (follow up to #23273)
- `()` now returns a valid empty `TUPLE`
- `(x,)` (with a trailing comma) is parsed as a single-element tuple
(python style)
- `(a, b, c,)` - trailing commas are ok for tuple literals in general.

This also round-trips in string conversions, e.g. `(1,)::VARCHAR` is
printed with a trailing comma.

### JSON/Parquet/Arrow/`VARIANT` conversion

This PR also adds support for json/parquet/arrow conversion of tuples.

- For JSON and `VARIANT`, we follow the python convention and turn
tuples into arrays.
- For parquet and arrow, we turn the tuples into structs with dummy
names, `element1, element2, ... elementN`, following the same convention
as when `UNNEST`ing a tuple.

### Storage Compatibility

- We preserves backwards (and forwards) compatibility by transparently
serializing tuples as empty structs when targeting old database
versions, and deserializing empty structs as tuples when reading them.
- This also means that we can now store and persist `TUPLE`s in columns,
which was not supported for unnamed structs.
- Additionally, tuples and structs are trivially implicitly castable to
each other, so any (future) function signature changes should not affect
user code.

### C-API Compatibility

Similarly to how we deal with tuples in storage, we do not add a new
`DUCKDB_LOGICAL_TYPE_TUPLE`, but transparently represent tuples as
unnamed structs, and vice-versa. So any existing C-API code should just
work and not have to make any changes.

### Code Changes

I've made most of the internal struct type helper (e.g.
`StructType::GetChildren`) also work on tuples so that most of the
execution engine and extension code will remain oblivious to this
change. However, I've had to keep the `StructType::IsUnnamed` as we
somehow create (partially?) empty/unnamed structs in various places when
dealing with `VARIANT`s. This should be investigated and resolved in a
follow-up PR - ideally we should enforce the invariant that structs
cannot be unnamed all over the system and make the need for this
function redundant. Or maybe we decide that an empty string is a valid
struct member, given that structs can't have duplicate members anyway.
Either way we need to work it out.

There are also a bunch of `struct_` functions that could be simplified
and/or overloaded for TUPLEs. I've tried to keep the changes minimal in
this PR, but we should probably make another pass over these in the
future as well.

Covers duckdb-web #6921 (duckdb/duckdb#23273). Notes that STRUCT types
may be empty, with a New in 2.0 callout, and links it from the What's
New in the Docs for 2.0 page.