Fixes duckdb#14699

…hod (duckdb#14708)

Fixes duckdb#14701

duckdb#14711)

This PR does some clean-up in the Value interface and serialization:

* `Value::EMPTYLIST` and `Value::EMPTYARRAY` are removed, instead the
interface `Value::LIST(type, values)` can be used to generate an empty
list/array
* `Value::MAP` and `Value::STRUCT` now correctly insert casts to enforce
that the values are internally consistent with the defined types
* `LogicalType::ANY` is explicitly supported in nested value types - in
which case these types are ignored, i.e. we can do
`Value::LIST(LogicalType::ANY, values)` with a list of values of any
type
* Avoid unnecessary recursive type serialization: when serializing
nested values, we no longer need to serialize the type of every value if
the type is defined (i.e. not `LogicalType::ANY`). Instead, the type
from the upper-layer is used (i.e. if we have
`LogicalType::LIST(LogicalType::INT)`, the child elements are
deserialized as `LogicalType::INT`).
* For backwards compatibility, we still serialize the type in every
`Value` also in nested values, unless the serialization version is set
to `>= 1.2.0`.

…ot have root_dir in Python < 3.10)

This PR fixes various nightly CI issues, e.g. fixing some new warnings
that are breaking builds

This PR adds support for the `.decimal_sep` and `.thousand_sep` options
that can be used in the CLI to configure how these are rendered. Note
that this is only respected in `duckbox` mode currently. Example usage:

```sql
.decimal_sep ,
.thousand_sep _
SELECT 12345.6;
┌──────────────┐
│   12345.6    │
│ decimal(6,1) │
├──────────────┤
│     12_345,6 │
└──────────────┘
```

Note that there is one restriction - this currently does not work with
nested types yet but only for numbers at the top-level.

)

Supersedes duckdb#12359

This PR adds a new property to functions - `FunctionCollationHandling`.
This can be used to handle collations across different functions in an
easy way. There are three settings:

* **PROPAGATE_COLLATIONS (default)**: Propagate collations, but do not
apply them. This means that if the function returns `VARCHAR`, and any
of the input arguments are `VARCHAR`, the return type will inherit the
collations of the input arguments.
* **PUSH_COMBINABLE_COLLATIONS**: Propagates collations and applies
**combinable** collations prior to calling the function. Combinable
collations are "simple" collations like `nocase` and `noaccent`, but not
`icu` collations that are more complex.
* **IGNORE_COLLATIONS**: Ignore collations entirely.

`PUSH_COMBINABLE_COLLATIONS` is used for various functions, e.g.
`contains`, `starts_with`, `glob`, `like`, etc:

```sql
D SELECT 'hello' COLLATE NOCASE LIKE '%HEL%' AS result;
┌─────────┐
│ result  │
│ boolean │
├─────────┤
│ true    │
└─────────┘
```

)

fixes duckdblabs/duckdb-internal#3180

And this is a followup to duckdb#13617 

If the table being filtered is large enough, the order of the
expressions will get moved around due to adaptive filtering. To prevent
this, expression reordering now places severe penalties on expressions
that can throw, effectively forcing them to be executed last. Then
during adaptive filters, we set the likelihood of swapping filters that
can throw to 0. This allows other filters to be swapped, but not
filters. that can throw.

…14713)

This PR implements duckdb#14696

This allows function calls that take lambda expressions to be made
through the expression API

Should hopefully fix duckdb#14636
(can't test on that hardware).