Refactor hard-to-maintain lists

[m-mohr]

In the best practices we have lists of relation types, media types etc. With the slow release cycle of the main spec, this is getting outdated quickly and it's relatively hard to maintain the list. I'd propose to clean-up the list and maintain it separately. For example, the list of relation types seems for some still relatively "unmature" (origin seems to be the card4l extension), but we list them regardless in the main spec, which is weird.

Similarly, I'd propose to remove the list of stable extensions from the extensions page and instead just link to stac-extensions.github.io.

[cboettig]

👍 Thanks @m-mohr !

Would love to see a more extensive, probably crowd-sourced list of what people are using for media types for different assets. https://github.com/radiantearth/stac-spec/blob/master/best-practices.md#common-media-types-in-stac is a nice start but obviously hardly scratches the surface of types.

Meanwhile, are their any guidelines for winging this? I'm not hopeful that we'll ever get registered MIME types for most of these (how long have we been waiting for parquet to get a MIME type??) I'm currently trying to document some vector objects that use flatgeobuf, and ESRI's shapefile and geodatabase formats; wondering if the GDAL driver names might provide a reasonable basis of reference: https://gdal.org/drivers/vector/index.html , e.g. application/x-<DRIVER SHORT NAME> maybe?

Or maybe that's a fools errand and we're better off omitting the type field and just providing a human-readable explanation of the file format using title or description fields?