This PR follows up on #15119 with:
- Switching the HTTP Logger to use the new logging infrastructure by
default (logging to a file is still possible using old setting)
- Adds a new mechanism for FileHandle logging
- Refactoring the loggers to support structured logging

My apologies for the slightly chaotic PR here. It took a few tries to
understand what makes sense here and I still feel like we are not 100%
there yet. However, this *should* be a decent step in the right
direction.

## FileHandle logging

This PR adds logging infra for filehandles. Basically what I wanted is
to create a unified way to log of the FileSystem APIs. I think this can
be very useful, for example in testing/optimizing Iceberg/Delta
workloads, but also to easily analyze IO patterns of our various readers
like the parquet reader, json reader, or avro readers. Since the log
messages will be in JSON format, they are easy to parse and do analysis
on.

Heres a demo:

```
D set enable_logging=true;
D set logging_level='trace';
D COPY (SELECT 1 as a) TO './test.csv';
D FROM "./test.csv";
┌───────┐
│   a   │
│ int64 │
├───────┤
│   1   │
└───────┘
D SELECT message FROM duckdb_logs WHERE type = 'FileSystem';
┌───────────────────────────────────────────────────────────────────────────┐
│                                  message                                  │
│                                  varchar                                  │
├───────────────────────────────────────────────────────────────────────────┤
│ {"fs":"LocalFileSystem","path":"./test.csv","op":"OPEN"}                  │
│ {"fs":"LocalFileSystem","path":"./test.csv","op":"WRITE","bytes":"2"}     │
│ {"fs":"LocalFileSystem","path":"./test.csv","op":"WRITE","bytes":"1"}     │
│ {"fs":"LocalFileSystem","path":"./test.csv","op":"WRITE","bytes":"1"}     │
│ {"fs":"LocalFileSystem","path":"./test.csv","op":"CLOSE"}                 │
│ {"fs":"LocalFileSystem","path":"./test.csv","op":"OPEN"}                  │
│ {"fs":"LocalFileSystem","path":"./test.csv","op":"READ","bytes":"4"}      │
│ {"fs":"LocalFileSystem","path":"./test.csv","op":"READ","bytes":"0"}      │
│ {"fs":"LocalFileSystem","path":"./test.csv","op":"CLOSE"}                 │
└───────────────────────────────────────────────────────────────────────────┘
```

### Implementation
While conceptually simple, the complexity lies in the fact that we want
to generally log to the ClientContext to ensure the log entries have
connection level context info. This is done by changing what was
previously a `unique_ptr<Logger>` to a `shared_ptr<Logger>` in the
Client context and copying the pointer to the logger into the
filehandles on creation. What this means is that a filehandle will log
using the logging configuration of the client context that created it.
because for now filehandles will not outlive the clientcontext that
created it, this is fine, but in theory this can create some confusion
if we were to share filehandles between connections or even between
queries. I think we probably just want to ensure we don't keep
filehandles open between queries.

I've created some macros for standardization of the common filehandle
operations that we want to log:
```C++
#define DUCKDB_LOG_FILE_SYSTEM_READ(HANDLE, ...)  DUCKDB_LOG_FILE_HANDLE_VA(HANDLE, "READ", __VA_ARGS__);
#define DUCKDB_LOG_FILE_SYSTEM_WRITE(HANDLE, ...) DUCKDB_LOG_FILE_HANDLE_VA(HANDLE, "WRITE", __VA_ARGS__);
#define DUCKDB_LOG_FILE_SYSTEM_OPEN(HANDLE)       DUCKDB_LOG_FILE_HANDLE(HANDLE, "OPEN");
#define DUCKDB_LOG_FILE_SYSTEM_CLOSE(HANDLE)      DUCKDB_LOG_FILE_HANDLE(HANDLE, "CLOSE");

```

Then in the code, for example in the `LocalFileSystem::Read()` we can
easily call the logger in an efficient way with the centrally defined
log type and level for the FileHandle logging:

```C++
DUCKDB_LOG_FILE_SYSTEM_READ(handle, bytes_to_read, location);

```

which will ensure that extension that implement their own filesystems
will be able to easily adhere to the logging convention.

## Logging refactor
To neatly support writing structured log messages, this PR makes a few
conceptual overhauls to the logging.

First of all, we remove the log types as manually passed string. In the
initial logging implementation, you would log like:

```C++
DUCKDB_LOG_<level>(context, "<log type string>", "message");
```
However these manually provided strings are not really practical and
likely to result in utter chaos.

We change this now to:

```C++
// Default log type (empty string for now)
DUCKDB_LOG_<level>(context, "message");

// Predefined log type
DUCKDB_LOG(context, LogTypeClassName, "message");
```

The `DUCKDB_LOG` macro is defined as 

```C++
DUCKDB_LOG_INTERNAL(SOURCE, LOG_TYPE_CLASS::NAME, LOG_TYPE_CLASS::LEVEL, LOG_TYPE_CLASS::ConstructLogMessage(__VA_ARGS__))
```

Which will ensure that the logs types can only be created using the
corresponding log message construction methods. The `LogType` class will
then also contain the logic to deserialize the log message string into a
predefined datatype for easy parsing.

What this allows us to do is to easily enable a specific log type, and
let DuckDB automatically deserialize and unnest the resulting data:

```SQL
PRAGMA enable_logging('FileSystem');
FROM './test.csv'
SELECT fs, path, bytes, pos FROM duckdb_logs_parsed('FileSystem');
```
which yields:
```
LocalFileSystem	test.csv	OPEN	NULL	NULL
LocalFileSystem	test.csv	READ	4	0
LocalFileSystem	test.csv	READ	0	4
LocalFileSystem	test.csv	CLOSE	NULL	NULL
```

Note that `duckdb_logs_parsed` is simply a table macro for:

```SQL
SELECT * EXCLUDE (message), UNNEST(parse_duckdb_log_message(log_type, message))
FROM duckdb_logs
WHERE type = log_type
```

## TODOs
Some general follow ups:
- Add logging to azure
- Add logging to fsspec 
- Add logging to #16463
- More benchmarking
- Make HTTPLogType a structured type

A more complex follow up is to think about how to make this performant.
Currently, enabling `PRAGMA enable_logging('FileSystem');` coulld become
quite expensive be cause it needs to string compare the the logging type
for every single `TRACE` level call. For now we actually get away with
it because we only add the logger to the filehandle if that the time of
filehandle creation we are logging for `FileSystem`. However, as soon as
we were to add more Trace level calls that are hit a lot during
execution, things will likely slow down fast.

External File Cache (duckdb/duckdb#16463)
[Dev] Add "registries" to `vcpkg.json`, add script to list the packages of the registry. (duckdb/duckdb#17124)

External File Cache (duckdb/duckdb#16463)
[Dev] Add "registries" to `vcpkg.json`, add script to list the packages of the registry. (duckdb/duckdb#17124)

External File Cache (duckdb/duckdb#16463)
[Dev] Add "registries" to `vcpkg.json`, add script to list the packages of the registry. (duckdb/duckdb#17124)