Fixes related to:
* duckdb/duckdb#20564
* duckdb/duckdb#20508
* duckdb/duckdb#20547

This PR updates submodules to latest available and adds minor
adjustments (required by duckdb/duckdb#20508 and other changes).

This PR updates submodules to latest available and adds minor
adjustments (required by duckdb/duckdb#20508 and other changes).

This PR updates submodules and adds a number of minor changes:

 - update `duckdb` submodule to the latest `v1.5-variegata`
 - update `extension-ci-tools` submodule to the latest `main`
 - update `MainDistributionPipeline.yml` to the same versions of the
   engine and CI tools as above
 - update `Linux.yml` to set `LOCAL_EXTENSION_REPO` env var that is now
   (after some recent `unittest` chage) is required to run tests with
   extensions that are not statically linked (otherwise
   `require postgres_scanner` fails)
 - apply patch `getdatainternal.patch` from the engine repo
 - add a change to `postgres_storage.cpp` to accomodate to changes added
   in duckdb/duckdb#20508
 - update `attach_types.test` that started failing due to
   duckdb/duckdb#20361 change

PS: due to changes required for duckdb/duckdb#20508 it is suggested to
add `v1.4-andium` branch to this repo (on a current `main`).

This PR updates submodules to latest available and adds minor
adjustments (required by duckdb/duckdb#20508 and other changes).

…extend functionality/speed up retrieval (duckdb#20508)

Follow-up from duckdb#18447

The previous PR introduced a concept of "generic settings" - which are
settings that don't need to exist as variables in the code as before.
The advantages of these settings are as follows:

* Generic settings can be set both globally and locally, instead of
having a fixed "position" of where they are assigned
* Accessing these settings does not rely on direct variable access - as
a result accessing / modifying these settings can be made thread-safe,
etc
* These settings are better aligned with extension-provided settings,
since they cannot have non-generic variables in the DBConfig and
ClientConfig
* Less code needs to be generated to support these settings

The idea behind these settings is that we migrate all settings to these
generic settings as much as possible (and ideally we migrate all of
them).

The main change made in this PR is to migrate many more settings to this
framework. Furthermore, this PR improves generic settings in a number of
ways:

* Accessing generic settings is now done through a `Settings` class
instead of through the `DBConfig`. This is less verbose and requires
only including the `settings.hpp` file instead of requiring an include
of both the `DBConfig` and `settings.hpp`.

```cpp
Settings::Get< EnableExternalAccessSetting>(context);
```

* Add support for having generic settings that can **only** be set
globally or **only** be set locally. This is done through providing a
`scope`. The following options are now possible:

```py
 # can only be set globally
"scope": "global"
 # can only be set locally
"scope": "local"
# can be set both locally and globally, defaults to global if not specified explicitly
"default_scope": "global" 
 # can be set both locally and globally, defaults to local if not specified explicitly
"default_scope": "local"
```

* Improve performance of accessing generic settings by avoiding `Value`
casts. In a follow-up PR I'm working on further improving performance.