…and use this in the aggregate HT to cache look-ups (#15196)

Follow-up from #15152

This PR enables the caching of results computed for dictionaries across
vectors by (optionally) assigning them with a unique identifier. The
identifier is a string that needs to be unique so we can distinguish
between a vector having the same dictionary or a different dictionary as
the previous vector. It does not have to be globally unique (i.e. really
only in the same pipeline for the same thread).

* For our own storage, the dictionary id is set to the `ColumnSegment`
pointer address. Since we never de-allocate `ColumnSegments` while
scanning this works
* For Parquet dictionaries, the dictionary id is set to
`[parquet_filename]_[column_name]_[byte_offset]`

Add dictionary size, and use dictionary/constant vectors in the aggregate hash table to speed up finding groups  (duckdb/duckdb#15152)
Fix Regression workflow running against itself (duckdb/duckdb#15165)
Fix wrongly used github.ref to sha (duckdb/duckdb#15167)
Add cross-version testing CI (duckdb/duckdb#15161)

Add dictionary size, and use dictionary/constant vectors in the aggregate hash table to speed up finding groups  (duckdb/duckdb#15152)
Fix Regression workflow running against itself (duckdb/duckdb#15165)
Fix wrongly used github.ref to sha (duckdb/duckdb#15167)
Add cross-version testing CI (duckdb/duckdb#15161)

Add dictionary size, and use dictionary/constant vectors in the aggregate hash table to speed up finding groups  (duckdb/duckdb#15152)
Fix Regression workflow running against itself (duckdb/duckdb#15165)
Fix wrongly used github.ref to sha (duckdb/duckdb#15167)
Add cross-version testing CI (duckdb/duckdb#15161)

Add dictionary size, and use dictionary/constant vectors in the aggregate hash table to speed up finding groups  (duckdb/duckdb#15152)
Fix Regression workflow running against itself (duckdb/duckdb#15165)
Fix wrongly used github.ref to sha (duckdb/duckdb#15167)
Add cross-version testing CI (duckdb/duckdb#15161)

Add dictionary size, and use dictionary/constant vectors in the aggregate hash table to speed up finding groups  (duckdb/duckdb#15152)
Fix Regression workflow running against itself (duckdb/duckdb#15165)
Fix wrongly used github.ref to sha (duckdb/duckdb#15167)
Add cross-version testing CI (duckdb/duckdb#15161)

Co-authored-by: krlmlr <krlmlr@users.noreply.github.com>

PR #15152 added support for
_dictionary aggregation_: when figuring out which group a value belongs
to, we only figure this out once per unique value, if the vector is a
dictionary vector coming from storage.

This PR implements _dictionary functions_: when evaluating a scalar
function on a dictionary vector, we evaluate it once per unique value.
This has two benefits: 1) less time is spent evaluating the function, as
it is evaluated on less values, and 2) the resulting vector is again a
dictionary vector instead of a flat one, allowing for subsequent
dictionary optimizations.

For dictionaries that a larger than a `STANDARD_VECTOR_SIZE`, we loop
over the dictionary, executing the function on at most
`STANDARD_VECTOR_SIZE` values at a time, similar to the approach in the
list functions. The most efficient approach would be to execute the
function on the entire dictionary at once, but some functions assume
that inputs are never larger than `STANDARD_VECTOR_SIZE`, so this is not
feasible. To avoid copying data between intermediate vectors and the
resulting dictionary, I've added the restriction that both the input and
output must be non-nested.

After implementing this, I noticed that the optimization was almost
never triggered for columns compressed with `DICT_FSST`. This was due to
a restriction that the start of vectors must be aligned with our
bitpacking group size, which only has a 1/32 chance of happening. We
don't have this restriction for regular dictionary compression, so I was
able to remove the restriction using the same approach used there.

Small benchmark (same table as PR
#15152):
```sql
-- generate data
CREATE TABLE strings AS
SELECT CONCAT('thisisastringwithrepetitions', i%100) AS grp, i
FROM range(100_000_000) tbl(i);
-- query
SELECT SUM(b)
FROM (
    SELECT grp LIKE '%42%' b
    FROM strings
);
```

For this query, `LIKE` is converted to the `contains` function, which is
executed on the dictionary.

| main [s] | this PR [s] |
|-|-|
| 0.082 | __0.024__ |

The previous query is sped up by more than 3x. The gains are even higher
for more expensive functions, especially when the output of the function
becomes a group for dictionary aggregation:
```sql
SELECT grp, SUM(i)
FROM (
    SELECT regexp_extract(grp, '[0-9]+') AS grp, i
    FROM strings
)
GROUP BY grp;
```

| main [s] | this PR [s] |
|-|-|
| 2.154s | __0.075s__ |

This query is sped up by almost 30x.

This is currently only implemented for `BoundFunctionExpression`, but it
can be implemented for `BOUND_CASE`, `BOUND_CAST`, etc. in future PRs.