Add ST_OffsetCurve

ST_OffsetCurve (offset a line to one side by a distance) is a common PostGIS construction missing from duckdb-spatial. GEOS already provides `GEOSOffsetCurve_r`, and its joinStyle and mitreLimit arguments are the same enums the styled ST_Buffer variant already maps, so **this is close to a clone of styled ST_Buffer minus the cap style**.

| Signature | Notes |
|---|---|
| `ST_OffsetCurve(line, distance)` | defaults quad_segs 8, join round, mitre_limit 5 |
| `ST_OffsetCurve(line, distance, quad_segs, join_style, mitre_limit)` | full styled form |

Positive distance offsets to the left of the directed line, negative to the right (GEOS convention).

| join_style | GEOS | Esri offsetHow (for ArcGIS porters) |
|---|---|---|
| round | GEOSBUF_JOIN_ROUND | esriGeometryOffsetRounded |
| mitre | GEOSBUF_JOIN_MITRE | esriGeometryOffsetMitered |
| bevel | GEOSBUF_JOIN_BEVEL | esriGeometryOffsetBevelled |

Implementer tip, **the 5 argument variant has 5 columns and DuckDB core ships no 4 or 5 column executor helper** (only Unary, Binary, Ternary, and larger). The styled ST_Buffer already handles this many arguments, so mirror that approach. PostGIS reference, `ST_OffsetCurve` in `lwgeom_geos.c` is a thin wrapper over the same call.

Open question, explicit numeric and keyword arguments like the styled ST_Buffer, or a PostGIS style parameter string. The explicit form looks more consistent with duckdb-spatial.

Sharing this as research in case it helps whoever picks it up.

Start by reading the existing styled ST_Buffer implementation and the GEOSOffsetCurve_r call described in the issue; compare the argument mapping and executor registration. Done means both listed ST_OffsetCurve signatures work with the stated defaults, join styles, mitre limit, and positive/negative distance conventions.

Written by the indexing model from the issue text.