[Enh]: Support `Geospatial` data type in MSSQL

# Geospatial data types

In SQL Server and Azure SQL Database, geospatial data is represented using the `geometry` and `geography` data types. These types store spatial data such as points, lines, and polygons, and support rich spatial operations like distance, containment, and intersection.

```sql
CREATE TABLE locations (
id INT PRIMARY KEY,
position GEOGRAPHY -- a latitude/longitude point
)
```

* `GEOGRAPHY` is used for Earth-based (ellipsoidal) coordinates (e.g., GPS).
* `GEOMETRY` is used for flat, projected coordinate systems (e.g., CAD/GIS).

## FOR JSON support

When used with `FOR JSON`, spatial columns are **serialized as strings** in SQL Server.

```sql
SELECT id, position FROM locations FOR JSON AUTO;
```

Returns:

```json
[
{
"id": 1,
"position": "POINT(-104.9903 39.7392)"
}
]
```

The output is a well-known text (WKT) representation of the spatial data.

## Inserting geospatial data

```sql
INSERT INTO locations (id, position)
VALUES (
1,
geography::STPointFromText('POINT(-104.9903 39.7392)', 4326)
);
```

* The `STPointFromText` method accepts WKT format and a spatial reference ID (SRID).
* `4326` is the most common SRID, representing GPS coordinates (WGS 84).

## Data API builder behavior

Data API builder (DAB) should treat geospatial columns as **WKT strings** for both reading and writing.

### Query operations

DAB will expose `GEOGRAPHY` or `GEOMETRY` values as WKT strings in REST responses:

```json
{
"value": [
{
"id": 1,
"position": "POINT(-104.9903 39.7392)"
}
]
}
```

### Mutation operations

When creating or updating rows, input should be a WKT string that SQL Server can parse:

```http
POST /locations
Content-Type: application/json

{
"id": 2,
"position": "POINT(-122.4194 37.7749)"
}
```

Internally, DAB should convert this into a call to `geography::STPointFromText(...)` with SRID `4326`.

### Geospatial Considerations

1. DAB must validate or wrap WKT strings using `STGeomFromText` or `STPointFromText`.
2. All values must include a valid SRID, typically `4326` for GPS.
3. DAB does not parse or visualize spatial data—clients are responsible for rendering.

Aucun fichier d’implémentation ni test n’est nommé. Commencez par localiser la gestion des types SQL Server de DAB ainsi que les chemins REST de mutation et de réponse, puis vérifiez comment les types de base de données existants sont représentés. Le travail est terminé lorsque les colonnes GEOGRAPHY et GEOMETRY sont exposées sous forme de chaînes WKT pour les lectures et acceptées pour les écritures, avec une couverture du comportement documenté de SQL Server.

Rédigé par le modèle d'indexation à partir du texte de l'issue.