Include `spatial_extras` options in `GpfGetFeature(ById)Layer` tools

[LionelZoubritzky-IGN]

PR #171 introduced the Gpf...Layer tools that produce a proxy URL that can be fed to any browser to fetch the full geometry corresponding to a query. The spatial_extras options from #165 were intentionally kept out of these new tools (#171 (comment)): the idea was that the full geometry was already returned, so there was no need to include extra computation results done on this geometry. Another objection was that the returned object need to be a fully valid GeoJSON, which the spatial_extras could hamper.

I propose revisiting this position. Indeed:

1. The spatial_extras are included as foreign members of the returned GeoJSON, which is completely valid in GeoJSON (https://datatracker.ietf.org/doc/html/rfc7946#section-6.1). The ubiquitous feature_ref is already included as a foreign member, so it should make no difference.
2. The LLM may want to access both the full geometry and some spatial_extras like the centroid or the bbox, in order to run some dedicated Python script on it. In that case, it has two choices:
   • either do two calls: one to get the layer and another to get the spatial_extras. That's relatively easy for the LLM, but it is somewhat counter-intuitive and it puts twice as much stress on the server.
   • either only do the layer call, then recompute the spatial_extras on the obtained geometry. But that requires writing dedicated code which is already present in the MCP, so it seems wasteful.

so I thinks we should re-allow the spatial_extras options in the Gpf...Layer tools. By default, spatial_extras are empty so this won't break anything.