GTI stac-geoparquet driver assumes 'image' asset name

[scottyhq]

What is the bug?

PR #10696 added support for the GTI driver to work with stac-geoparquet format, which is really neat! However, it seems to identify stac-geoparquet files by the presence of an asset with an 'image' key:

gdal/frmts/gti/gdaltileindexdataset.cpp

Lines 895 to 897 in 1344d8d

	// Is this a https://stac-utils.github.io/stac-geoparquet/latest/spec/stac-geoparquet-spec ?
	const bool bIsStacGeoParquet =
	poLayerDefn->GetFieldIndex("assets.image.href") >= 0;

Because asset keys are not standard, there are many stac geoparquets without this key. While you can overridde this by setting LOCATION_FIELD it seems this skips automatically getting proj:epsg proj:transform fields as described in the docs (https://gdal.org/en/latest/drivers/raster/gti.html#stac-geoparquet-support)

Steps to reproduce the issue

ERROR 1: Cannot find field location

AZURE_STORAGE_ACCOUNT=pcstacitems \
AZURE_STORAGE_SAS_TOKEN=`curl -s https://planetarycomputer.microsoft.com/api/sas/v1/token/pcstacitems/items | jq -r '.token'` \
gdalinfo GTI:/vsiaz/items/io-lulc-annual-v02.parquet

Note that assets in this collection are "data", "rendered_preview", and "tilejson"
https://planetarycomputer.microsoft.com/api/stac/v1/collections/io-lulc-annual-v02/items/60L-2017

Versions and provenance

gdal                              3.10.0        py312h9e5d920_1       1.6 MiB    conda  gdal-3.10.0-py312h9e5d920_1.conda
libgdal-arrow-parquet             3.10.0        h0c53206_1            715.3 KiB  conda  libgdal-arrow-parquet-3.10.0-h0c53206_1.conda

Additional context

As an alternative stac-geoparquet can be identified by file-level metadata "geo" key (https://geoparquet.org/releases/v1.1.0/)

Or individual STAC Items can also be identified by the presence of a required stac_version property (https://github.com/radiantearth/stac-spec/blob/master/item-spec/item-spec.md)