Writing a KML produces garbled ExtendedData

Reproduction steps:

```sql
INSTALL spatial;
LOAD spatial;
CREATE TABLE foobar AS (
SELECT '' as name, '' as description,
'2' AS prop1, 'first' AS prop2, 'hello world' AS prop3, 'last' as prop4
ST_Point(3, 4) as geometry
);
COPY foobar TO 'foobar.kml' (FORMAT GDAL, DRIVER 'KML');
```

which results in:
```xml

foobar


2

first

last

3,4

```

Several sub-problems:
1. Even if name and description columns exist (or are specified with NameField, DescriptionField in `LAYER_CREATION_OPTIONS`), the first two columns other than the specified or auto-detected name and description fields are always included as secondary tags (and by the looks of it, popped off the list of available values during serialization). On its own this preserves all fields (provided they're string-typed), shifting values two property keys down.
2. Non-string fields end up in the schema (good), but are removed from the list of available field names during generation of `SimpleData` tags *along with the value for that field's index*. This both truncates the number of fields, and shifts key-value pairings unpredictably.

Point (2) is slightly tricky to spot - accounting for the effects of point (1) and assuming non-string columns are ignored, the first `SimpleData` tag should be `hello world`.

---

By the sounds of https://github.com/geopandas/geopandas/issues/3609 , it's a problem specific to the built-in kml driver; flipping the `OGR_ENABLE_DRIVER_LIBKML`, `GDAL_USE_LIBKML` flags on and marking libkml as a dependency of GDAL works perfectly, but I gather there are reasons duckdb-spatial doesn't have that on by default.

Confirmed on 1.1.0 and upwards.