Add best practice of HTML version of 'Items' and 'Catalogs

[cholmes]

One important piece discussed at the boulder sprint was to have an HTML / human-readable version of each item. It was decided that the JSON one should be the core standard, but HTML should be encouraged with examples and tooling. HTML pages should be optimized for human consumption, so won't all look the same.

But it'd be good to make some examples and create tooling that can take JSON items and make HTML ones that can sit in static catalogs. The html should have lots of links, display thumbnails, display product and collection level information, and when possible have a slippy map backed by dynamic COG tiling. Perhaps even put up comments (using disqus might be an easy route there).

[cholmes]

This was discussed a bit on #378 and on the call on April 22.

There's been great progress since this issue was created, with tools like https://github.com/radiantearth/stac-browser/ working and deployed like http://planet.stac.cloud

But we should add to the 'best practices' sections in the spec, likely in the catalog section, but link from the item spec too.

[m-mohr]

STAC Browser is a great tool. I was just wondering whether it can integrate with APIs directly and thus support content negotiation. So if I request /collections/foo with an Accept: text/html (e.g. in the browser) could I get a STAC Browser based output for the browser and if I request the same url with Accept: application/json (e.g. from a STAC Downloader) could I get the JSON response? That would be very useful and thus we wouldn't need to deploy the tool somewhere else but could integrate it directly into out APIs. If this is not possible with STAC browser, we would need best practices how to generate this HTML (e.g. include the JSON-LD mapping, #378).

Maybe this would be better suited as issue in STAC browser though? cc @mojodna

[matthewhanson]

resolved with PR #437